JDK-8352533 improved the IOE messages in case Runtime.exec fails; this can be improved to give the user better information in case of these common errors:

a) POSIX_SPAWN: jspawnhelper is broken, wrong architecture (cannot be exec'd), missing, has no exec permissions, FileSystem has no exec permissions
b) POSIX_SPAWN: jspawnhelper crashed out with a signal
c) FORK+POSIX_SPAWN: same for the target binary
d) FORK+POSIX_SPAWN: argument vector or env vector too long
e) FORK+POSIX_SPAWN: pathnames too long
f) FORK+POSIX_SPAWN: we ran against the max number of allowed processes

This is also needed since we want to remove VFORK mode, and the requirements for the CSR to proceed (https://bugs.openjdk.org/browse/JDK-8357090) is to have better analysis methods when customers that use VFORK today are switched to POSIX_SPAWN.

Notes:
- no changes for VFORK needed since we will throw that stuff out anyway soon
- Minimal costs, no additional system calls. Runtime.exec is already expensive enough. The best way to implement this would be to process the error return values of the various fork/exec/posix_spawn calls.

POSIX_SPAWN mode:
- (a), (f) can be detected by processing the errno from posix_spawn of jspawnhelper
- (b) can be observed at the waitpid stage in the parent.
- (c) (d) (e) can be observed at the exec of the target binary in jspawnhelper

FORK mode:
- (f) can be detected by processing the errno from the initial fork() call
- (a) .. (e) can all be observed by processing the errno from the subsequent exec call in the child process

A clean, simple method must be found to transmit the error codes back to the parent process. Ideally by complementing/super-imposing the returned error code in the fail pipe.

Important: we need good regression tests for these, if at all feasible.