Silence an uninitialized value warning.

As per precedent about 15 lines earlier in file, with respect to same
variable.
Fix spurious "uninitialized value" warning in regex match

The warning appeared if the pattern contains a floating substring for
which utf8 is needed, and the target string isn't in utf8.  In this
situation, downgrading the floating substring yields undef, which
triggers the warning.

Matching can't succeed in this situation, because it's impossible for
the non-utf8 target string to contain any string which needs utf8 for
its own representation.  So the warning is quelled by aborting the match
early.

Anchored substrings already have a check of this form; this commit makes
the corresponding change in the floating-substring case.
regexec.c: PATCH: [perl #114808]

Commit c72077c4fff72b66cdde1621c62fb4fd383ce093 fixed a place where
to_byte_substr() fails, but the code continued as if it had succeeded.

There is yet another place where the return is not checked.  This commit
adds a check there.

However, it turns out that there is another underlying problem to
[perl #114808].  The function to_byte_substr() tries to downgrade the
substr fields in the regex program it is passed.  If it fails (because
something in it is expressible only in UTF-8), it permanently changes
that field to point to PL_sv_undef, thus losing the original
information.  This is fine as long as the program will be used once and
discarded.  However, there are places where the program is re-used, as
in the test case introduced by this commit, and the original value has
been lost.

To solve this, this commit also changes to_byte_substr() from returning
void to instead returning bool, indicating success or failure.   On
failure, the original substrs are left intact.

The calls to this function are correspondingly changed.  One of them had
a trace statement when the failure happens, I reworded it to be more
general and accurate (it was slightly misleading), and added the trace
to every such place, not just the one.

In addition, I found the use of the same ternary operation in 3 or 4
consecutive lines very hard to understand; and is inefficient unless
compiled under C optimization which avoids recalculating things.  So I
expanded the several nearly identical places in the code that do that so
that I could quickly see what is going on.
sv.c: perlapi pod grammar
Fix infinite loop with $tied =~ s/non-utf8/utf8/

Commit 3e462cdc208 fixed bug #41530 (s/non-utf8/utf8/ was not working
properly at all) by upgrading the target and redoing the substitution
if the replacement was utf8 and the target was not.

Commit c95ca9b8cd1 fixed one problem with it calling get-magic too
many times, by checking whether the upgrade caused a string realloca-
tion and only then redoing the substitution.  But it only fixed it
when magic returns a pure ASCII string.

Redoing the substitution meant going back to where the target was
initially stringified and starting again.  That meant calling get-
magic again.

So in those cases where magic returned something other than a UTF8 or
pure ASCII string the substitution restarted and magic would be trig-
gered again, possibly resulting in infinite loops (because it would
have to be upgraded again, resulting a reallocation, and a restart).

This happens with:

• Latin-1 strings
• Copy-on-write non-UTF8 strings
• References that stringify without UTF8

c95ca9b8cd1 also added SvPVX without checking first that it is SvPVX-
able, so a typeglob causes an assertion failure.

It turned out that there were also two other places in pp_subst that
were calling FETCH a second time (the tests I added for the looping/
assertion bugs found this), so I changed them, too.