Bugfix: no hole in liveranges for pinned vreg move src.

[cfallin]

Right now, pinned vregs are a way of naming real registers (a
compatibility shim of sorts for Cranelift's RealRegs) and can be used
as sources and dests of moves. When the input program does so, regalloc2
converts these into "ghost" uses and defs on the other vreg of the move
(dest or source, respectively) with a fixed-register constraint. So
move v128, v0 where v0 is pinned to p0 turns into a "ghost def"
on v128 with constraint fixed p0.

There is some fancy manipulation of liveranges to make this all work
while properly recording where the preg's value must be preserved.
Unfortunately, there was an off-by-one in the location of the move and
transition of live-ranges which interacts poorly with the "implicit
live-in" of pinned vregs at function start. As a result, a function body
that starts like:

    move v128, v0
    def v9000
    move v129, v1

might allocate p1 (to which v1 is pinned) for v9000. This clobbers
the original value.

Fortunately this only impacts the implicit live-in, and Cranelift's use
of regalloc2 is such that it will always copy all values out of pinned
vregs (creating ghost defs) without intervening defs, except in the
case of sret ("structure return") arguments. If a program does not use
sret arguments (and the cranelift-wasm frontend does not), then this
bug should not be reachable.

Long-term, we really need to kill pinned vregs with fire (#3); the
special cases that arise from these, and from special handling of moves,
are too much incidental complexity. All of this can go away once
Cranelift migrates all fixed-register cases to operand constraints
instead. That will be a happy day.

Thanks to @bjorn3 for finding and reporting this issue!

[cfallin]

My plan for this re: other PRs: we will want to land this first, and do a 0.2.3 release of regalloc2, and then do a point-release of Cranelift that bumps the RA2 dep. Then we'll want to land #58 and #59 and version-bump to 0.3, since #58 changes the API slightly.