Propagate Debugging Identifiers through Lambda

[spiessimon]

This PR propagates identifiers for debugging (of type debug_uid = Shape.Uid.t) from the typed tree representation through the Lambda IR. It is based largely on #1912, but already addresses the comments mentioned in that PR. It is also substantially smaller, because the propagation stops after the Lambda IR.

The intended semantics of the debugging identifiers is as follows:

• User visible variables (i.e., variables which exist at the source level) are associated with a debugging identifier. All other (internally generated) variables can freely use Lambda.debug_uid_none.
• The "ground truth" for the identifiers is the typed tree. We create them at this level to store relevant shape information for debugging.
• From the typed tree, we must propagate the identifiers through the lower level representations. This PR takes care of propagating them through Lambda and, for now, simply drops them once we reach Flambda.

In general, it is fine to duplicate a debug_uid in Lambda or lower (contrary to what the name indicates), since for debugging information it is only important that we can map the lower level representations to the source variables that they correspond to (and their types). Moreover, I did not take much care to find the correct debugging identifiers for modules and classes. I left several comments in places where it seems like we could provide additional debugging identifiers, but it's not clear to me that it is worth it in these cases.

Suggestions for reviewing. The easiest way to review this PR is probably by following the flow of the compiler with one exception: it probably makes sense to take a look at the changes in lambda.mli first to see which Lambda constructs will get a debugging identifier.