[runtime] Make sure mono_create_handler_block_trampoline is async signal safe.

We call mono_create_handler_block_trampoline when installing the block guard,
so this function must be async safe at that stage in the runtime.

Since it is eagerly called during startup, we should be fine with just
memory barriers.
[runtime]Properly compute the end address of a finally block when it ends in a dead basic-block.

We compute the end address of a finally block by using cil_offset_to_bb, which can point to dead
basic blocks if those were killed by CFG simplification.
[runtime]Generate the proper exit code for block guard trampolines.

Finally blocks use a non-standard calling convention which means we need to take it
into account in the return address hijacking trampoline.

A finally block is called with ESP % 16 == 4. Once inside the finally block, ESP returns
to be % 16 == 0 due to the call instruction pushing the return address.

The problem comes when we want to hijack the return address. Our trampolines expect a
normal calling convention with ESP properly aligned, so we use a small thunk of code that
does that before jumping into the trampoline itself. This is required as we'll enter native.

The problem lies on the exit path as the trampoline jump to an arbitrary place instead back
to the above thunk. This leaves the stack with the thunk adjustment in, which will cause
the resulting code to misalign the stack even further.

The solution, though a big ugly, is to change the exit path of the trampoline fix the stack
to be "properly" misaligned.
Add tests for the recently fixed issues with block guards.