doio.c: Use SvREFCNT_dec_NN

The sole use of SvREFCNT_dec in doio.c is on a variable than is
never null (setdefout would fail an assertion otherwise), so
no need to check whether it is.
Switch dump.c over to using SvREFCNT_dec_NN

No uses of SvREFCNT_dec in dump.c are ever passed null SVs, so
don’t check for that.
Use SvREFCNT_dec_NN in gv.c

Various SvREFCNT_dec calls in gv.c are never given null pointers,
so there is no need to check for them.

I added one const mostly for code documentation purposes
(so one can see at a glance that the variable won’t change).
hv.c: hv_undef: Don’t set mro fields to null before freeing

There is no point in modifying a struct just before freeing it.

This was my mistake, in commit 47f1cf7702, when I moved the code from
S_hfreeentries to hv_undef.
Move File::DosGlob from lib to ext
Increase $File::DosGlob::VERSION to 1.09
DosGlob: Don’t use the magic 2nd arg to glob

Use the address of the glob op instead.

This argument is going away, because it is undocumented, unused on
CPAN outside of the core, and may get in the way of allowing glob() to
be overridden properly.

Another reason is that File::DosGlob leaks memory, because a glob op
freed before iteration has finished will leave File::DosGlob still
holding on to the remainder of the list of files.  The easiest way to
fix that will involve using an op address instead of a special index,
so there will be no reason to keep it.
File::Glob: Don’t use the magic 2nd arg to glob

See the previous commit.  The same applies to File::Glob as well.

In short, the easiest way to fix a memory leak involves using the
address of the glob op rather than a special glob index.
Don’t pass PL_glob_index to glob overrides

This magic second argument is undocumented and unused on CPAN and in
the core (as of the last few commits).

It could also get in the way of making glob truly overridable in the
future (e.g., allowing File::Glob to take a list).
Stop using PL_glob_index for PL_globhook

If Glob.xs just uses the address of PL_op as its iterator key all the
time (when called via PL_globhook too, not just via a glob override),
the code is simpler.
Zap PL_glob_index

As of the previous commit, nothing is using it.
pp.h: Remove tryAMAGICunTARGET

This macro is unused on CPAN and completely undocumented, so this
change should be safe.
Remove the second param to tryAMAGICunTARGETlist

This parameter is no longer used.  Its value is always 0.
Increase $File::Glob::VERSION to 1.19
Don’t leak when partly iterated glob op is freed

File::Glob keeps its own hash of arrays of file names.  Each array corresponds to one call site.  When iteration finishes, it deletes
the array.  But if iteration never finishes, and the op at the call
site is freed, the array remains.  So eval "scalar<*>" will cause a
memory leak.

We already have a mechanism for hooking the freeing of ops.  So
File::Glob can use that.
Fix problems with -Dr during global destruction

$ cat foo
my $x = '(?{1})';
BEGIN { $^H |= 0x00200000 } # lightweight "use re 'eval'"
"a" =~ /a$_/ for $x;

If I run this under PERL_DESTRUCT_LEVEL=2 with the -Dr flag on a non-
threaded build, the output ends with this:

 during global destruction.
 during global destruction.
 during global destruction.
 during global destruction.
 during global destruction.
Attempt to free temp prematurely: SV 0x822610 during global destruction.
Attempt to free temp prematurely: SV 0x802340 during global destruction.
Attempt to free temp prematurely: SV 0x8222d0 during global destruction.
Attempt to free temp prematurely: SV 0x822490 during global destruction.
Attempt to free temp prematurely: SV 0x8224f0 during global destruction.
Scalars leaked: 5

And sometimes I even get assertion failures.  (I suspect hash random-
isation gives me the inconsistent results.)

t/re/recompile.t happened to trigger this bug, producing noisy output.
Since the assertion failures were in sub-processes, the tests passed
anyway.  In this commit I have changed the test to check the status of
the sub-processes, too, before reporting a pass.

This bug appears to have started happening in v5.17.0-424-gd24ca0c,
but I don’t know why.  I suspect it was a latent bug waiting
to happen.

During global destruction, all objects are freed, the main stash is
freed, and then various SVs in interpreter variables are also freed.
Finally, if PERL_DESTRUCT_LEVEL is set, there is one last sweep of all
remaining SVs.  It is during that sweep that this bug occurs.

When the -Dr flag is present, freeing a regular expression causes the
${^RE_DEBUG_FLAGS} flags variable to be looked up.

Symbol lookup can trigger the ‘Global symbol requires package name’
error (which becomes a warning here, due to the way pp_ctl.c:qerror
works).  The code that produces that error assumes that if there is
no stash then the preceding code has detected an attempted stricture
violation.

The preceding code actually tries to provide PL_defstash (aka %main::)
as the stash to look in, since this is a punctuation variable.  But
PL_defstash has been set to null.

The logic that no stash equals a stricture violation is there-
fore faulty.

The attempt to output that error message uses a temporary scalar which
is placed on the mortals stack.  Freeing of the items on the mortals
stack happens before this SV sweep, and not during or afterwards, so
the SV sweep ends up trying to free those mortals itself.  There is a
check in sv_free2, enabled under debugging builds, to see whether the
SV is on the mortals stacking.  If it is, a warning is emitted and the
SV is not freed.

My initial attempt at fixing this was to try to avoid putting a mortal
on the stack in this case.  The code in question doesn’t actually need
to use the mortals stack, since Perl_mess isn’t going to croak, so it
can free the SV itself.  That takes care of the ‘Attempt to free temp
prematurely’ warnings and the final ‘Scalars leaked’.  It doesn’t
solve the ‘during global destruction’ message, but I decided to leave
it in place anyway, since creating an SV and freeing it is a little
more efficient that creating it, pushing it on to the mortals stack,
and having FREETMPS free it later.

That ‘during global destruction’ message is supposed to say ‘Global
symbol...’, but diagnostic messages during global destruction use the
same SV, so it’s not suprising that it gets stomped on before it makes
its way to qerror.  I’m not sure where it gets stomped on, but it’s
not relevant; we need to get rid of the message altogether.

The final solution is to skip the ‘Global symbol...’ error altogether
while sv_clean_all (the final SV sweep) is being called, which we can
detect based on whether PL_in_clean_all is set.