compiler/arm/c-call: Relieve register pressure during CALL-OUT.

  * Several things wrong here, including a previously unexplored
constraint.  We have an NFP which is component-live, up to four
C arguments passed in registers, and only five unboxed registers
to work with...  And a temporary bound to an unboxed register and
the function to call being passed in a SAP-REG which is also
unboxed.  That makes seven pounds of s...tuff in a five pound bag.

  * First, the temporary is used to hold the address of
call_into_c, which is word-aligned, and thus looks like a FIXNUM
to the GC.  Thus, it can go in an ANY-REG.

  * Second, about the only place that we can put FUNCTION that
will be acceptable to the compiler (due to primtype restrictions)
and that we can get at is the number stack, so force it to
SAP-STACK instead of SAP-REG, and use a LOADW (cribbed from
LOAD-NUMBER-STACK) to get at it.

  * This brings our register pressure on CALL-OUT down about as
low as it can get, and it should be low enough to cover the
maximum number of C register arguments.
compiler/arm/c-call: Relieve register pressure immediately before CALL-OUT.

  * The REPRESENT phase of the compiler emits a SAP-MOVE VOP for
the FUNCTION parameter to CALL-OUT, because it has to coerce it
from a SAP-REG (even if it's possibly been spilled) to a SAP-STACK.

  * In high register pressure scenarios (more than three
parameters to an alien function), the value has already been
spilled to the number stack, so the SAP-MOVE VOP doesn't actually
generate any code, but because the compiler doesn't decide to
spill the value until during the PACK phase, it has to assume that
the SAP-REG TN for the SAP-MOVE is live (lifetime analysis is done
pre-PACK).  Unfortunately, our register pressure is so high that
we don't have enough registers for this.

  * But we could still take the FUNCTION in a SAP-REG if we wanted
to, and this would completely eliminate the VOP introduced by
REPRESENT, meaning that our register pressure relaxes just enough
that we can handle an alien function with four register parameters
(the maximum number of register parameters, the rest are passed on
the stack).

  * Accept both SAP-REG and SAP-STACK for the FUNCTION argument,
using SC-CASE to determine how to load the value into its target
register for the call.
compiler/arm/c-call: Allow integer stack arguments during CALL-OUT.

  * It looks as though the code from the PPC backend does the
right thing for us, so simply enabling it should at least get us
the TNs that we need.
compiler/aliencomp: Lower register pressure in ALIEN-FUNCALL.

  * On ARM, our register pressure is so tight that we have no free
non-descriptor registers available after loading four register
arguments, which means that we can't load stack arguments.

  * So, the old switcheroo: Process the stack arguments first.
This makes the wired register argument TNs live only after we need
a free register for processing the stack argument TNs, thus
relieving the pressure sufficiently to be able to compile a call
with stack arguments.
compiler/arm/values: Define VOP RESET-STACK-POINTER.

  * Cribbed from the PPC backend, this is required in order to
implement (%POP-VALUES IR2-CONVERT), which was a disabled bit of
IR2TRAN.