Don’t coerce $x immediately in foo(substr $x...)

Don’t coerce $x immediately in foo(substr $x...)

This program:

    #!perl -l
    sub myprint { print @_ }
    print substr *foo, 1;
    myprint substr *foo, 1;

produces:

    main::foo
    Can't coerce GLOB to string in substr at - line 4.

Ouch!

I would expect \substr simply to give me a scalar that peeks into the
original string, but without modifying the original until the return
value of \substr is actually assigned to.

But it turns out that it coerces the original into a string immedi-
ately, unless it’s GMAGICAL.  I find the exception for magical varia-
ble rather befuddling.  I can only imagine it was for efficency (since
the stringified form will be overwritten when magic_setsubstr calls
SvGETMAGIC), but that doesn’t make sense as the original variable can
itself be modified between the return of the special lvalue and the
assignment to that lvalue.

Since magic_setsubstr itself coerces the variable into a string upon
assignment to the lvalue, we can just remove the coercion code from
pp_substr.

But that causes double uninitialized warnings in cases like
substr($undef, 0,0) = "lrep".

That happens because pp_substr is still stringifying the variable (but
without modifying it).  It has to do that, as it looks at the length
of the original string and accordingly adjusts the offsets stored in
the lvalue if they are negative or if they extend beyond the end of
the string.

So this commit takes the simple route of avoiding the warning in
pp_substr by only stringifying a variable that is SvOK if called in
lvalue context.

Hence, assignment to substr($tied...) will continue to call FETCH
twice, but that is not a new bug.

The ideal solution would be for the offsets to be translated in mg.c,
rather than in pp_substr.  But that would be a more involved change
(including most of this commit, which is therefore not wasted) with
potential backward-compatibility issue with negative numbers.

A side effect it that the ‘Attempt to use reference as lvalue in
substr’ warning now occurs during the assignment to the substr lvalue,
rather that substr itself.  This means it occurs even for tied varia-
bles, so things are now more consistent.

The example at the beginning could still croak if the glob were
replaced with a null string, so this commit only partially allevi-
ates the pain.