JIT: support immediate stores
Merge pull request #805 from FioraAeterna/storerefactor

JIT: support immediate stores
Wrap some function calls in ABI_Push|PopRegistersAndAdjustStack(0, 0);

These calls are made outside of JIT blocks, and thus previously did not
read any protection - register use is taken into account and the outer
dispatcher stack frame is sufficient.  However, if data is to be stored
on the stack, these calls must reserve stack shadow space on Windows to
avoid clobbering it.
Opportunistically predict BLR destinations using RET.

When executing a BL-type instruction, push the new LR onto the stack,
then CALL the dispatcher or linked block rather than JMPing to it.  When
executing BLR, compare [rsp+8] to LR, and RET if it's right, which it
usually will be unless the thread was switched out.  If it's not right,
reset RSP to avoid overflow.

This both saves a trip through the dispatcher and improves branch
prediction.

There is a small possibility of stack overflow anyway, which should
be handled... *yawn*
Shorten the blr stub a bit.
Run exception handlers on an alternate stack on Linux.

*Completely untested.*  Someone please test.
Reorganize backpatching a bit.  Untested on ARM.

Rather than *MemTools.cpp checking whether the address is in the
emulated range itself (which, as of the next commit, doesn't cover every
kind of access the JIT might want to intercept) and doing PC
replacement, they just pass the access address and context to
jit->HandleFault, which does the rest itself.

Because SContext is now in JitInterface, I wanted JitBackpatch.h (which
defines it) to be lightweight, so I moved TrampolineCache and associated
x64{Analyzer,Emitter} dependencies into its own file.  I hate adding new
files in three places, two of which are MSVC...

While I'm at it, edit a misleading comment.
Be pedantic about stack overflow on Linux and OS X.

Add some magic to the fault handler to handle stack overflow due to BLR
optimization, and disable the optimization if fastmem is not enabled.