Static check for noalloc: ignore allocations post-dominated by a raise

[gretay-js]

Adapted from another part of #707.

This PR adds attributes [@noalloc_exn ] and [@noalloc_exn assume] which are similar to [@noalloc] and [@noalloc assume], respectively, added in #825, except the allow allocation and indirect calls post-dominated by a raise.

The way we currently determine post-dominators is conservative around try-with and some other cases, so might not be able to prove everything that the user expects.

[gretay-js]

Rebased on top of #870 to rename the attributes. This PR is now using [@noalloc] instead of [@noalloc_exn], as suggested by @lpw25. The motivation for this change is that this "relaxed" interpretation of the check is likely to be more useful in practice and should have a shorter name. Note that the meaning of this new attribute has already diverged from the meaning of [@@noalloc] on external which forbid raising exceptions from C stubs.

To distinguish the two, we could use [@zero_alloc] for the new attribute, with the corresponding [@zero_alloc_strict].

I've also updated the PR to check allocation paths on paths leading to [raise_notrace], so that allocations will only be ignored if postdominated by a raise with a backtrace, which is intended for error handling.

[gretay-js]

The handling of try-with is not right, thanks @poechsel for this example:

try raise (Exn n) with Exn n -> n

the non-strict check passes, but the intended meaning here is for a check to fail because there is allocation on the “normal” return of this expression. Thanks @lpw25 for this definition. To implemented it not overly conservatively I think we can use the result of the strict check for the body of the try. I am making this PR into a Draft for now.

[Gbury]

Can we close this one since #1157 has been opened ?

[gretay-js]

superseded by #1157