More lambda/matching documentation

[gasche]

@trefis and myself met today to work on #7241 together, and our first order of business was to read, document and refactor when useful some parts of the code that remained obscure to us in the past -- and had become obscure to @maranget when we discussed this a couple months ago.

This PR contains no behavior change, only documentation comments and some minor refactorings.

@Octachron has done a first round of in-person review.

[lthls]

I've looked at all the commits, and I think they're safe, and the comments do help a little bit.

I have some doubts about the commit that switches the order of elements in a list (ddb9fad): the list is not used as an association list in any obvious way, and the comment still states that the list is ordered without specifying which order (if I understand correctly, it only means that order has meaning in this list, and that it's not just a dictionary). So I think switching to a record would have made sense, but switching the order of the tuples doesn't seem particularly useful.
The rest of the comments are not enough for me to understand how the algorithm works, but they don't feel misleading so I'd rather have them than not.

[gasche]

the list is not used as an association list in any obvious way

Correct: a pair (i, matrix) represents an exit-handling clause of the form

| exit i -> <compiled matrix>

but we never List.assoc into this list. We still believe that it is expected to have the exit number before the exit handler code. (This is also more consistent with the other exit-indexed structure in the code, namely jump summaries -- Jumps.t.)

the comment still states that the list is ordered without specifying which order (if I understand correctly, it only means that order has meaning in this list, and that it's not just a dictionary)

Yes, the ordering that matters is the source order -- not preserving it would break the top-down priority order of matching clauses.