t/op/lex.t: Fix test

It was a copied-and-pasted repeat of another test, both of which I
added in commit 67a057d6d.  I know it used to crash and the commit
fixed it, as I tested it at the time with one-liners.
scalar(%h = (1,1,1,1)) should return 4, not 2

perldoc perlop says:

    a list assignment in scalar context returns the number of elements
    produced by the expression on the right hand side of the assignment

Behaviour was changed as side effect of
ca65944e8ff8fff6e36ea7476ba807be16cfe2a9 where goal was to fix
return value in list context.
test "Odd number of elements in hash assignment"
warn on ($s,%h) = (1,{}) as on %h = {}

Latter results in "Reference found where even-sized list expected"
message while former produces "Reference found where even-sized list
expected". Quite inconsistent.
test hash assignment with odd elements for leaks

if key scalar is tied and dies on fetch then hash assignment
is leaking a key value
fix issues in hash assignment with odd elements

1) unify code path of processing odd case with regular
loop that process pairs. fixes memory leak when key
is magic and dies on fetch.

2) in list context put undef that we added to compensate
odd elements into returned values, so (%h = (1))
returns (1, $h{1}) rather than (1). This is documented
in perldoc perlop:

    a list assignment in list context produces the list
    of lvalues assigned to.

Here can be a dispute, but:

* that key without value on RHS is still assigned with
  undef
* consider (%h = (1,2,3,4,5,6,3)). Returning (1,2,3,undef,5,6)
  is much easier than (1,2,5,6,3).
* order of returned elements follows cases with even number
  of elements on RHS and duplicates

3) hash assignment with duplicates and odd elements on
RHS was returning wrong results in list context.
Now (%h = (1,1,1)) returns (1,$h{1}).
make sure hash assignment is proper lvalue
hash assign in list context should copy key as well

if we don't then returned keys are aliases for RHS
values and can result in unexpected changes
test return values of aassign with various elements on LHS

* hash on LHS followed by array, other hash or scalar,
  for example (%h, @a) = (...);

* above with normal RHS, with duplicates, odd elements
  and combination.

* inspect elements returned by aassign for lvaluedness

* assign doesn't return elements that were just cleared
we need duplicates counter only in list context
ary/hash/firsthashelem should be set only once

Only once for first hash or array, otherwise
(%h,@a) = ... assignment returns wrong results
for duplicates and/or number of elements on RHS.
refactor aassign

move populating stack with return values. Place it
into main loop right after we stored values.

This allow us to delete special if blocks for
hash/array on LHS followed by other hash/array.

Also, clearing HV out of ENTER/LEAVE block is bad -
segfaults in corner cases.

Don't use goto for odd elements case.

store undef on stack for odd case. we can avoid NULL
checks in the loop and use assert like array assignment
does.

use SvSETMAGIC rather than repeate what it means.

for array and hash assignment "while (relem <= SP)" loop
at the end was always empty. Put it into else branch.
don't create a copy of keys if it's not LVALUE context

Making another copy slows things down. We can avoid it
if aassign is not expected to return LVALUEs.
pp_hot.c:pp_aassign: mortalise variable only if we have to

This affects the hash-assignment path.

Don’t mortalise the value to protect it from a magical key making the
hv_store_ent call die, as that could unduly extend the mortals stack.

Instead, copy the key if it is magical.

Based on a patch by Ruslan Zakirov.
hash argument is not used anymore in do_oddball

rename arguments to make more clear what function takes
Copy keys for aassign in lvalue sub

Checking LVRET (which pp_aassign does, as of a few commits ago)
has no effect if OPpMAYBE_LVSUB is not set on the op.  This com-
mit changes op.c:op_lvalue_flags to set this flag on aassign ops.

This makes sub:lvalue{%h=($x,$x)} behave correctly if the return
values of the sub are assigned to ($x is unmodfied).
hashassign.t: Test undef explicitly

thereby eliminating uninit warnings
hashassign.t: Suppress oddball warnings
pp_hot.c: Comments to clarify pp_aassign

[The committer took these from <201210240658.q9O6w1u25266@crypt.org>
and turned them into a patch.]
[Merge] hash assignment fixes and speedup

In <CAMOxC8vCaYk3GD0NRH=jxGmNKu+bmKTrYKR2nsrgU6Wei+xmYQ@mail.gmail.com>
Ruslan Zakirov wrote:
> I've finished my work on pp_aassign. I find it ready for review.
> Each commit has plenty of details, but here is short description:
>
>     * scalar(%h = (1,1,1,1)) returns 4, not 2
>     * warn on ($s,%h) = (1,{}) as on (%h) = ({})
>     * (%h = (1)) in list context returns (1, $h{1})
>       instead of (1)
>     * return of (%h = (1,1,1)) in list context was incorrect
>     * in list context returned keys was aliased to RHS scalars
>       of aassign
>     * returned list from ((%h, @a) = ...), hash on LHS followed by
>       array or hash, was incorrect
>     * implemented right to left algorithm for not magic hash assignment
>       in scalar and void context
>     * use less mortals is list context
>     * in list context hash assignment return keys aliased to RHS
>       when it's ok (it's not LVALUE context)