Handle list assignment in list context better

Handle list assignment in list context better

In something like

    sub inc { $_++ for @_ }
    inc(($a,$b,$c,$d) = (10,20))

The four scalar vars will end up with the values (11,21,1,1), with
the list assign op returning 4 lval scalars to be passed to inc.

However, when the LHS includes a hash or array, any 'empty' scalars weren't
being returned. This:

    inc(($a,$b,@array,$c) = (10))

used to leave $b and $c undefined. With this commit, they are both set to
1.

This change broke some tests in hashassign.t, which were added in 2012
by commit v5.17.6-295-gb1babc5. Half these tests were commented as

    # this arguable, but this is how it works

and they all tested that a scalar following a hash wasn't returned in
lvalue context; i.e. they all assumed that

    inc((%h, $x) = (...))

*wouldn't* increment $x. This commit causes $x to be incremented, and
I've changed the failing tests.

It also adds an EXTEND(SP,1) in the scalar case; otherwise with
scalar( () = @a) and empty @a, it could in theory push the '0' return
value off the end of the stack.