chore: improve terminology consistency

[s-tikhomirov]

Description

Rationale

This PR aims to introduce consistent usage of terms throughout the code to make sure that:

• variable and function names reflect their essence;
• the same thing is called the same name;
• different things are called different names;
• naming is consistent with the spec.

Making terminology consistent will hopefully make it easier to review substantial changes to the contract both in the context of the currentlu open membership-related PRs (#13, #14) as well as for future modifications.

Terminology

To remain consistent with the spec and between different pieces of code, the following term usage is suggested. This PR implements (but is not limited to) these guidelines:

Recommended	Not recommended	Comments
Membership	Member, User	By using "animate" notions like "member" or "user", we open up the discussion on who the user is, what distinguishes one users from multiple users, whether one user can register multiple memberships, etc. In the scope of the smart contract, the basic unit we account for is a membership.
Membership set	Set, Tree (exceptions apply)	The membership set is the central concept of the RLN protocol. The fact that it is implemented as a Merkle tree, in particular a LazyIMT, is an implementation detail. The suggestion is to use the phrase "membership set" whenever possible, unless dealing with tree-specific functions like getting a Merkle proof. (Although even that can be called "inclusion proof" or something.) When using the word "tree" or its derivatives, clarify in the comments that this tree stores the membership set (or, even more precisely, the rate limits of memberships in the membership set).
Rate limit	Limit, message limit	The term "rate limit" corresponds to the spec and also is consistent with the term "rate commitment".
Rate commitment, Id commitment	Commitment	There are two types of commitments in the code: rate commitments and ID commitments. Using just the word "commitment" can be confusing, as it's not immediately clear which commitment we're talking about. The suggestion is to always specify the type of commitment, including in derivative names of variables and functions, like getRateCommitment.

Checklist

Ensure you completed all of the steps below before submitting your pull request:

• Added natspec comments?
• Ran pnpm adorno?