Transform tail-recursive functions into recursive continuations

[Ekdohibs]

This pull request introduces the transformation of tail-recursive calls in functions to a recursive continuation call, effectively transforming the function into a loop at the flambda2 stage and allowing further simplifications to be done (such as unboxing). By default, this transformation only happens if the function is purely tail-recursive as written (no instance of the function exists other than in a tail call in the body).
The [@loop] and [@loop never] attributes are added to control the transformation, the first by forcing the transformation to happen even if the function is not detected to be tail-recursive (for instance, if some calls are hidden behind inlining), while the second prevents the transformation from ever happening.
Since loop unrolling is not yet supported, the [@unrolled] attributes are incompatible with loopified functions, and the optimizer will warn about impossible inlining. If unrolling is important in those situations, the function can be marked with [@loop never] to present its transformation.

--
This is a rebase of #836 on top of all the parts that were split from it.

[mshinwell]

When this is finalised, a short description in a Github comment on this PR would be useful, so we can communicate to users exactly when this transformation will take effect.

[Gbury]

All seems good (modulo a few comments here and there). There's one thing that I wonder about: how hard would it be, when simplifying an apply_expr, to make the decision to loopify a particular call after the decision of whether to inline/unroll the call ?

[Ekdohibs]

Rebased for the conflict with poll attributes.

[lthls]

@Gbury reviewed the core algorithm in simplify/; the rest looks fine.