This implements tailcall-via-help support for all platforms supported by
the runtime. In this new mechanism the JIT asks the runtime for help
whenever it realizes it will need a helper to perform a tailcall, i.e.
when it sees an explicit tail. prefixed call that it cannot make into a
fast jump-based tailcall.

The runtime created two important IL stubs to help the JIT in performing
the necessary tailcalls. One IL stub is used to store the args for the
tailcall, while the other is used to dispatch the actual tailcall
itself. The JIT will then transform the call from

return tail. F(a1, ..., an);

to

IL_STUB_StoreTailCallArgs(a1, ..., an);
T result;
IL_STUB_DispatchTailCalls(..., &result);
return result;

The dispatcher is written in such a way that it is able to dispatch
multiple tailcalls in a row when tailcalled functions also perform
tailcalls. To do this, the JIT helps the dispatcher detect if the
caller's caller is also a dispatcher. When this is the case the
dispatcher returns to let the previous dispatcher perform the tailcall
with the currently stored args. This allows the frame to unwind and
ensures that sequences of tailcalls do not grow the stack more than by a
constant factor.

Due to this unwinding the args cannot be stored on the stack and are
instead stored in TLS. The GC is made specially of this buffer as the
args can be anything, including interior pointers.

The control-flow when performing the new tailcalls is nonstandard, so
this also changes the debugger to support proper stepping into/over/out
of tailcalled functions when they go through the new dispatcher.

x86's tailcalling mechanism does not change.

…-helpers

…call-helpers

# Conflicts:
#	src/coreclr/src/inc/corinfo.h
#	src/coreclr/src/jit/morph.cpp
#	src/coreclr/src/tools/Common/JitInterface/CorInfoBase.cs
#	src/coreclr/src/tools/crossgen2/jitinterface/jitwrapper.cpp

# Conflicts:
#	src/coreclr/src/inc/corinfo.h
#	src/coreclr/src/tools/Common/JitInterface/CorInfoBase.cs
#	src/coreclr/src/tools/crossgen2/jitinterface/jitwrapper.cpp

…dress.

This mitigates cases where the tail call caller is not optimized
(e.g., when it's a static constructor) and a tail-prefixed intrinsic
is not expanded and then IL_STUB_CallTailCallTarget is optimized
and the intrinsic is expanded. In that case codegen for
NextCallReturnAddress is confused since there is no call.

# Conflicts:
#	src/coreclr/tests/issues.targets

Generate movw/movt instead of adr on arm. adr on arm allows offsets
up to 4k, which may not be enough. In particular,
IL_STUB_CallTailCallTarget uses GT_LABEL before argument setup code
and it can be more than 4k.

COMPlus_FastTailCalls controls whether fast tail calls are allowed.
If COMPlus_FastTailCalls is 0, fast tail calls are not allowed even for
tail-prefixed calls. Only helper-based calls are allowed. This is useful
for testing helper-based calls.

# Conflicts:
#	src/coreclr/src/jit/lower.cpp

When we have an indirect tail call, we may not be able
to figure out the target MethodDesc so we need to
use the type of the caller's 'this` argument to get the
correct type of the callee's this parameter.

Without this fix we were passing a `byref` as 'this' argument to
`IL_STUB_StoreTailCallArgs`, whose `this` parameter was typed as
`ref`. This lead to validation failures during GC. With the fix we
correctly set the type of the stub's `this` parameter as `byref`.

…HIS`.

# Conflicts:
#	src/coreclr/tests/issues.targets