lc.t: More tests for #43207
Reënable in-place lc/uc

It used to be that this code:

for("$foo") {
  lc $_;
  ...
}

would modify $_, allowing other code in the ‘for’ block to see the
changes (bug #43207).  Commit 17fa077605 fixed that by changing the
logic that determined whether lc/uc(first) could modify the sca-
lar in place.

In doing so, it stopped in-place modification from happening at all,
because the condition became SvPADTMP && SvTEMP, which never happens.

(SvPADTMP unually indicates an operator return value stored in a pad;
i.e., a scalar that will next be used by the same operator again to
return another value.  SvTEMP indicates that the REFCNT will go down
shortly, usually a temporary value created solely for the sake of
returning something.)

Now that bug #78194 is fixed, for("$foo") no longer exposes a PADTMP
to the following code, so we *can* now assume (as was done erroneously
before) that PADTMP indicates something like lc("$foo$bar") and modify
pp_stringify’s return value in place.

Also, we can extend this to apply to TEMP variables that have a ref-
erence count of 1, since they cannot be in use elsewhere.  We skip
TEMP variables with set-magic, because they could be tied, and
SvSETMAGIC would have a side effect.  (That could happen with
lc(delete $h{tied_elem}).)

Previously, this was skipped for uc and lc for overloaded references,
since stringification could change the utf8ness.  That is no longer
sufficient.  As of Perl 5.16, typeglobs and non-overloaded blessed
references can also enable their utf8 flag upon stringification, if
the stash or glob names contains wide characters.  So I changed the
!SvAMAGIC (not overloaded) to SvPOK (is a string already), which will
cover most cases where this optimisation helps.  The two tests added
to the end of lc.t fail with !SvAMAGIC.
pp.c: Improve self-referential comment

pp.c:pp_lc has this:

	    /* Here is where we would do context-sensitive actions.  See the
	     * commit message for this comment for why there isn't any */

If I try to look up the commit that added the comment, I get this:

commit 06b5486afd6f58eb7fdf8c5c8cdb8520a4c87f40
Author: Karl Williamson <public@khwilliamson.com>
Date:   Fri Nov 11 10:13:28 2011 -0700

    pp.c: White-space only

    This outdents and reflows comments as a result of the removal of a
    surrounding block

86510fb15 was the commit that added the comment, whose commit message
contains the explanation, so cite that directly.
pp.c: Simplify lc and uc stringification code

Originally, lc and uc would not warn about undef, due to an implemen-
tation detail.

The implementation changed in 673061948, and extra code was added to
keep the behaviour the same.

Commit 0a0ffbced enabled the warnings about undef, but did so by added
even more code in the midst of the blocks that existed solely to avoid
the warning.

We can just delete those blocks and put in a simple stringification.