Improve the semantics of asynchronous exceptions [old version]

[mshinwell]

This PR provides a way of making explicit the places where asynchronous exceptions may be raised. This in particular stops exceptions arising from allocation points and thus matches up with the model used by Flambda 2. One consequence is that the addition of safepoints will then work correctly with Flambda 2. This supercedes #194.

The asynchronous exceptions are now nicely wrapped up as follows:

exception Stack_overflow
exception Finaliser_raised of exn
exception Memprof_callback_raised of exn
exception Signal_handler_raised of exn

Uses of Out_of_memory that were asynchronous exceptions (there were some uses that were not) now terminate the program.

There is currently a new function Sys.with_async_exns that can be used to identify a point at which asynchronous exceptions should be emitted. There is also an experiment to implement the "bracket pattern" like in Haskell; see Sys.bracket. There is a file containing a couple of tests which will need to be much enhanced.

Asynchronous exceptions are funneled via a new exception pointer in the domain state, which points at normal trap frames, forming a second exception stack. The raising of asynchronous exceptions skips over traps that weren't inserted by with_async_exns. The second exception stack, save for the head which is in the domain state, is just held in what are effectively local variables in the caml_start_program / caml_callback code (albeit written in assembler).

Note that Stack_overflow is special and can be raised directly from a signal handler.

Joint work with @stedolan and @lpw25 .

[mshinwell]

There is one particular point worth noting: this PR, when compiling to native code, currently aims to deliver async exceptions only to handlers registered using Sys.with_async_exns. I think it's cleaner and easier to understand this way. (The alternative is that async exceptions could be permitted to be raised from function calls, for example.)
I also tend to think that maybe the term "asynchronous exceptions" shouldn't be used, in favour of something else, which would emphasise that this really is something different from normal exceptions. "Panic" has been suggested a bit like Rust, although I think the version here raises these in more restricted circumstances.

Regarding bytecode, async exns would end up being delivered to normal exception handlers, but we could still support masking.

[mshinwell]

Note on backward compatibility: currently this isn't backwards-compatible, since it requires Break to be caught as Signal_handler_raised Break. This is probably ok, since code would need to be updated to use Sys.with_async_exns anyway.

[mshinwell]

Superceded by #802