Use PADNAME rather than SV in the source

This is in preparation for making PADNAME a separate type.

This commit is not perfect.  What I did was temporarily make PADNAME a
separate struct identical to struct sv and make whatever changes were
necessary to avoid compiler warnings.  In some cases I had to add tem-
porary SV casts.
pad.h: Don’t use pad_compname_type

We only use PAD_COMPNAME_TYPE in one place, so wrapping it in a func-
tion doesn’t save us anything, and probably slows things down if
anything.  Furthermore, PadnameTYPE will soon become even simpler
than before.
Mathomise pad_compname_type
pad.c: Remove encoding handling

When encoding.pm affects variable names, it decodes them to UTF-8, and
when it doesn’t non-ASCII lexical variable names are prohibited.  So
this code is not necessary.
Make PADNAMELIST a separate type

This is in preparation for making PADNAME a separate type.
pad.c:padlist_dup: Remove refcnt check

This was added by 6de654a5, and the assert that makes sure the
reference count is exactly 1 was added in the same commit.  After
several years, I think we can be sure now that the reference count
is indeed always 1.  We don’t need to ‘play it safe’ for non-debug-
ging builds.
Make pad names always UTF8

Prior to 5.16, pad names never used the UTF8 flag, and all non-ASCII
pad names were in UTF8.  Because the latter was consistently true,
everything just worked anyway.

In 5.16, UTF8 handling was done ‘properly’, so that non-ASCII UTF8
strings were always accompanied by the UTF8 flag.

Now, it is still the case that the only non-ASCII names to make their
way into pad name code are in UTF8.  Since ASCII is a subset of UTF8,
we effectively *always* have UTF8 pad names.  So the flag handling is
actually redundant.

If we just assume that all pad names are UTF8 (which is true), then
we don’t need to bother with the flag checking.  There is actually
no reason why we should have two different encodings for storing
pad names.

So this commit enforces what has always been the case and removes the
extra code for converting between Latin-1 and UTF8.  Nothing on CPAN
is using the UTF8 flag with pads, so nothing should break.  In fact,
we never documented padadd_UTF8_NAME.
pad.c: Use UTF8f for ‘will not stay shared’

This is more efficient than creating a temporary SV.
diag.t: Allow multiline diag_listed_as
‘Subroutine (not var) "&x" will not stay shared’

Another ‘variable’ warning about lexical subs that I missed.
fetch_pad_names.t: Emit all test names

They were defined in the structure passed to the general_tests func-
tion, but not all of them were used.
perl.h: Add PNf and PNfARG

for pad names.  Currently equivalent to SVf(ARG), they will be changed
shortly when I make pad names a separate type.
Use PADNAME rather than SV in dump.c:debop
B.pm: Document upcoming PADLIST changes
B.pm: Clarify classes used for pad names
Prepare B::Concise for upcoming pad name changes

When pad names become their own type, separate from SVs, the ‘immor-
tal’ pad names, &PL_padname_undef and &PL_padname_const (to replace
&PL_sv_undef and &PL_sv_no), will no longer be B::SPECIAL objects,
but B::PADNAMEs.  The way to distinguish them is to check the
length.  This method happens to work both before and after the pad
name changes.
Increase $B::Showlex::VERSION to 1.05
Prepare B typemap for upcoming pad name changes
Add ‘immortal’ pad name intrp vars

These will replace the current use of &PL_sv_undef and &PL_sv_no as
pad names.
Use PADNAME rather than SV in op.c:finalize_op