Investigate spurious SIGSEGV at the end of injected_fn

[smx-smx]

On some platforms, at the end of injected_fn, a SIGSEGV is generated.
This is caught and cleaned up by ezinject, but it shouldn't happen

[smx-smx]

This issue is caused by injected_fn corrupting injcode_call, since it's pushed on the stack for the payload and we assume it can be overwritten.
However, at the end of injected_fn, the injected wrapper will reuse the libc_syscall pointer from the entrypoint to raise SIGSTOP.
Since this pointer can potentially be corrupted, we will jump to a random address and generate a SIGSEGV instead.

f066597 addresses a similar crash in Darwin by copying the wrapper parameters onto the injcode_bearing (which sits in its own dedicated memory).

The ideal solution would be to copy the whole injcode_call onto the injcode_bearing or (even better), split the parameters we rely upon from the rest and copying only those (so we don't copy unnecessary data)