Fix regression in &REST -> &MORE conversion caused by change a4393e3d.

Fix regression in &REST -> &MORE conversion caused by change a4393e3d.

1) A REF node to &REST var with no lvar-dest made REST-VAR-MORE-CONTEXT-OK
   think that the &REST arg had to be listified. I couldn't figure out
   why this wasn't an issue prior to the aforementioned revision,
   but it seems not to have been, though maybe it was.

2) The + and - functions should have used DO-REST-ARG but didn't,
   only because I didn't get to them yet, which should not have
   been a problem, except that their code actually got worse without.

Note- The problem that DO-REST-ARG tries to deal with is that %REST-REF
has an internal check for whether the index arg exceeds the more-count
because NTH is perfectly valid for N greater than the length of its
input list, and in general the user might write (NTH huge-num rest-arg).
But DO-REST-ARG never does that. Unfortunately the equivalent expressions
  (IF REST-VAR (CAR REST-VAR))
  (IF (> (LENGTH REST-VAR) 0) (NTH 0 REST-VAR))
  (IF (> MORE-COUNT 0) (NTH 0 REST-VAR))
would all effectively become
  (IF (> MORE-COUNT 0) (IF (< 0 MORE-COUNT) (%MORE-ARG...) NIL))
which contains two consecutive tests of the same condition.
Not only is constraint propagation unable to elide one test,
the compiler was sure that the "else" case of the inner IF causes
a type error in the form (THE NUMBER (<mumble>)).