pad.c:pad_alloc: Remove redundant IS_PADGV

GVs are stored in the pads in two code paths, newPADOP when called by
newGVOP, and ck_rvconst.  Both of those now set the pad name to
&PL_sv_no, as of c9859fbde1 and c2bad63bb3.  So by the time this
check is reached, IS_PADGV can never be true.
pad.c:pad_tidy: Remove redundant IS_PADGV

GVs are stored in the pads in two code paths, newPADOP when called by
newGVOP, and ck_rvconst.  Both of those now set the pad name to
&PL_sv_no, as of c9859fbde1 and c2bad63bb3.  So GVs are now excluded
from the check a few lines below, just like constants.
pad.c:pad_tidy: Remove IS_PADCONST and another IS_PADGV

Checking these is no longer necessary, since the only thing this loop
does is handle entries that close over variables from outer subrou-
tines.  IS_PADGV and IS_PADCONST will never be true for those.
pad.c:cv_clone_pad: Don’t bother with IS_PADGV

As of c9859fbde1 and c2bad63bb3, namesv && PadnamePV(namesv) will be
true for all pad GVs.
pad.c:pad_push: Don’t bother with IS_PADGV

As of c9859fbde1 and c2bad63bb3, PadnamePV(name) will be true for
all pad GVs.
pad.c:padlist_clone: Don’t bother with IS_PADGV

As of c9859fbde1 and c2bad63bb3, PadnamePV(name) will be non-null
for all pad GVs.
Change IS_PADGV to isGV in op.c:newPADOP

IS_PADGV is about to go bye-bye.  IS_PADGV was returning true only
for GVs marked as being present in the pad.  But since any GV can
make its way in there (just mention *foo under threads), it’s actually
somewhat meaningless.

This check in newPADOP is perhaps useless, too, since it is only called
by newGVOP in core (so sv is always a GV), and by B::Generate on CPAN,
which, again, gives it a GV.
Remove !IS_PADGV assertions

Commit 60779a30f stopped setting PADTMP on GVs in pads,
and changed many instances of if(SvPADTMP && !IS_PADGV) to
if(SvPADTMP){assert(!IS_PADGV)...}.

This PADTMP was leftover from the original ithreads implementation
that marked these as PADTMP under the assumption that anything in a
pad had to be marked PADMY or PADTMP.

Since we don’t want these GVs copied the way operator targets are
(PADTMP indicates the latter), we needed this !IS_PADGV check all over
the place.

60779a30f was actually right in removing the flag and the !IS_PADGV
check, because it should be possible for XS modules to create ops that
return copiable GVs.  But the assertions prevent that from working.

More importantly (to me at least), this IS_PADGV doesn’t quite make
sense and I am trying to eliminate it.

BTW, you have to be doubly naughty, but it is possible to fail these
assertions:

$ ./perl -Ilib -e 'BEGIN { sub { $::{foo} = \@_; constant::_make_const(@_) }->(*bar) } \ foo'
Assertion failed: (!IS_PADGV(sv)), function S_refto, file pp.c, line 576.
Abort trap: 6
pad.c: Stop turning on GvIN_PAD

This flag never really made any sense.  It allows us to identify
whether a GV is being used by a pad (e.g., for *foo under ithreads),
but *any* GV could have this set and there is no way to know whether
it was set for the pad we are currently looking at.
Only #define IS_(PADGV|CONST) if !PERL_CORE

and give IS_PADGV a simpler definition.

These are not used in the perl core any more and shouldn’t be.

The IS_PADGV definition checked for the IN_PAD flag, which flag never
made much sense (see the prev. commit’s message).  Since any GV could
end up with that flag, and since any GV coming near a pad would get
it, it might as well have been turned on for all GVs (except copies).
So just check whether the thingy is a GV.
Remove GVf_IN_PAD

Nothing on CPAN uses it, but some CPAN modules use the associ-
ated macros.
[Merge] Eliminate IS_PADGV etc.

The core no longer uses IS_PADGV, IS_PADCONST, or GvIN_PAD.  They were
no longer needed and never really worked properly.