Fix spawn dup ordering - #9578

The logic here, ported from CRuby, had two different orders in
which it could perform the dups. If the parent's state had already
been saved, as for forking, the dups should proceed in ascending
order of the child descriptors. If the parent's state had not
already been saved, as for a non-forking spawn, the dups should
proceed in ascending order of the parent descriptors, lest they
get overwritten by subsequent dups.

The logic in CRuby is very messy, due to splicing both forking and
non-forking logic together in the same methods, and the JRuby port
went astray here. We captured the parent state, but because we do
not fork we did not actually handle that state as thought we were
in a forked child. We did, however, proceed to use the order of the
child descriptors to indicate the order of the dups, which resulted
in `in: STDOUT` seeing and duping the wrong stdout (i.e. whatever
stream would eventually be the child's stdout). In the example
cases from jruby#9577, this could be the popen pipe (not a
terminal), /dev/null (also not a terminal), or whatever was passed
to popen via `out:` redirect. In the working case there, that
redirect is `out: STDOUT`, accidentally making the correct parent
stdout available in the child for the `in:` dup.

The fix is to always use the ordering of the input descriptors,
since posix_spawn will perform the redirects for us in that order,
and we don't want lower descriptors to be overwritten before we
have a change to deal with them.

Fixes jruby#9577