There is a problematic case when return address is hijacked while in a
managed method that tail calls a GC write barrier and when CET is
enabled. The write barrier code can change while the handler for the
hijacked address is executed from the vectored exception handler.
When the vectored exception handler then returns to the write barrier to
re-execute the `ret` instruction that has triggered the vectored
exception handler due to the main stack containing a different address
than the shadow stack (now with the main stack fixed), the instruction
may no longer be `ret` due to the change of the write barrier change.

This change fixes it by setting the context to return to from the
vectored exception handler to point to the caller and setting the Rsp
and SSP to match that. That way, the write barrier code no longer
matters.