Ensure consistent naming on MMR frontier code

[mmagician]

We could still iron out the terminology (MMR/frontier/SMT) but let's do that in a separate PR, I'll open a tracking issue.

Originally posted by @mmagician in #2245 (review)

[Fumuran]

Our current implementation uses both MMR (and its frontier) and SMT, but the resulting structure cannot be clearly represented by either of them or their combination, so I decided to describe the structure not in terms of its implementation, but in terms of its essence.

And essentially this structure holds the non-zero (non-canonical-zero) Merkle path nodes for the last added leaf to the SMT. These nodes are only used for the root computation of this SMT.

So maybe we can call the whole structure something like "Last Leaf Merkle Frontier", since it holds data only relevant to the last added leaf, and this data primarily consists of the frontier, which in turn is a truncated Merkle Path. In that case we will be able to distinct the structure itself, its frontier (LLMF frontier) and its root (LLMF root).

This is our internal structure with a relatively detailed documentation, so maybe it is fine if its name will be a bit weird. Wdyt?

[mmagician]

Two distinct things are getting conflated:

1. The Local Exit Tree (LET) - it's a protocol-level concept (AggLayer's name for it). Not concerned with the underlying data structure.
2. The frontier - the implementation-level data structure which we need for incrementally maintaining the LET root. This is an important distinction from a full Merkle tree which would imply full structure - while we only store the frontier. AggLayer calls this "branch" (worth mentioning this somewhere in the docs, but I think frontier here is more informative so let's stick to it in our codebase).
3. MMR - the structure somewhat resembles an MMR in how we update the internal nodes, and this is excellently explained in mmr_frontier32_keccak.masm already. In terms of the root though, we have a root that corresponds to a fixed-depth, canonical-zero initialized merkle tree.

I would suggest not to invent a new term - people outside this codebase would not know what LLMF means, whereas "Local Exit Tree frontier" is immediately clear if you know AggLayer. Some suggestions:

• Use "Local Exit Tree" / LET at the protocol/API boundary.
• Use "frontier" for the internals regarding updating and maintaining the underlying data structure.
• Drop "MMR" from user-facing names. The internal doc in mmr_frontier32_keccak.masm can still explain the MMR/SMT hybrid nature, but the API names shouldn't leak it (also I'd rename the file name to drop MMR, maybe merkle_tree_frontier?)