Ensure that Static recursive bindings always go through pre-allocation

[lthls]

This PR introduces a Constant classification and relies on it to ensure that Static bindings always get pre-allocated.

The patch is less simple than I would have liked for multiple reasons.

First, classes. The translation of classes (and all object code in general) generates recursive bindings that do not go through Rec_check. These bindings can be actually recursive, in which case they often match the shape of a Static binding, but when they're not actually recursive the compilation pass can also generate code that returns a function call, which should be Dynamic.
So it looks like we might have to patch the class compilation code so that it also returns the classification, but after a bit more digging it is not enough.
When I said "often" earlier, I left out cases like class c1 = object end and c2 = c1, which is compiled as an alias recursive definition which would normally be forbidden by Rec_check. But other checks on class definitions force these aliases to always occur after the classes they alias to, so as long as the compiler initializes the recursive bindings in the same order as the definitions the current scheme happens to work.
So my solution is to add a new classification for classes and keep the old behaviour in this case.
ocaml#8956 chooses another solution, which is to always pre-allocate classes (they are always blocks of size 4); I've left the possibility open here in a comment.

Second, Flambda can lift recursive definitions to symbols, transforming a Static binding into a Constant one. Typically, in the test letrec-compilation/record_with.ml, both records can be statically allocated. So I could either change the expression computations to dynamically detect constants, or patch the Flambda code to change the classification when appropriate. I chose the second option (but the first one might have been better, see next point).

Finally, the order of evaluation for recursive definitions depends on the classification (as shown by the test letrec-compilation/evaluation_order_1.ml), so I decided to be as precise as possible for the classification of constants, making the classification in Rec_check a bit more complicated than necessary.
In the end, it turns out that the test would pass even if the evaluation order changes; it only failed because Tree [] was classified as Static but the size computation treated it as a constant, so my new assertions triggered. Allowing Static bindings to be re-classified as constants during size computation, as discussed earlier, would have solved the problem.

[lthls]

I'm going to try the alternate solution discussed above, allowing switching from Static to Constant at any point and detecting that during the size computation.