[perl #114924] Make method calls work with ::SUPER packages

Perl caches SUPER methods inside packages named Foo::SUPER.  But this
interferes with actual method calls on those packages (SUPER->foo,
foo::SUPER->foo).

The first time a package is looked up, it is vivified under the name
with which it is looked up.  So *SUPER:: will cause that package
to be called SUPER, and *main::SUPER:: will cause it to be named
main::SUPER.

main->SUPER::isa used to be very sensitive to the name of the
main::FOO package (where the cache is kept).  If it happened to be
called SUPER, that call would fail.

Fixing that bug (commit 3c104e59d83f) caused the CPAN module named
SUPER to fail, because SUPER->foo was now being treated as a
SUPER::method call.  gv_fetchmeth_pvn was using the ::SUPER suffix to
determine where to look for the method.  The package passed to it (the
::SUPER package) was being used to look for cached methods, but the
package with ::SUPER stripped off was being used for the rest of
lookup.  3c104e59d83f made main->SUPER::foo work by treating SUPER
as main::SUPER in that case.  Mentioning *main::SUPER:: or doing a
main->SUPER::foo call before loading SUPER.pm also caused it to fail,
even before 3c104e59d83f.

Instead of using publicly-visible packages for internal caches, we
should be keeping them internal, to avoid such side effects.

This commit adds a new member to the HvAUX struct, where a hash of GVs
is stored, to cache super methods.  I cannot simpy use a hash of CVs,
because I need GvCVGEN.  Using a hash of GVs allows the existing
method cache code to be used.

This new hash of GVs is not actually a stash, as it has no HvAUX
struct (i.e., no name, no mro_meta).  It doesn’t even need an @ISA
entry as before (which was only used to make isa caches reset), as it
shares its owner stash’s mro_meta generation numbers.  In fact, the
GVs inside it have their GvSTASH pointers pointing to the owner stash.

In terms of memory use, it is probably the same as before.  Every
stash and every iterated or weakly-referenced hash is now one pointer
larger than before, but every SUPER cache is smaller (no HvAUX, no
*ISA + @ISA + $ISA[0] + magic).

The code is a lot simpler now and uses fewer stash lookups, so it
should be faster.

This will break any XS code that expects the gv_fetchmeth_pvn to treat
the ::SUPER suffix as magical.  This behaviour was only barely docu-
mented (the suffix was mentioned, but what it did was not), and is
unused on CPAN.
perldelta for #114924
g++ + mad fails t/run/mad.t

For some reason, g++ causes $^X to have a relative path when called
with one, whereas gcc causes it to have an absolute path:

g++:

$ ./perl -le 'print $^X'
./perl

gcc:

$ ./perl -le 'print $^X'
/Users/sprout/Perl/perl.git-copy/perl

(This is on 32-bit darwin.)

This affects mad.t’s ability to find the current perl interpreter
after a chdir.
t/run/mad.t: Avoid %ENV assignment

I see no skip on VMS, so use an %ENV localisation that it supports.
Handle xhv_super in thread cloning
${^LAST_FH}

This was brought up in ticket #96672.

This variable gives access to the last-read filehandle that Perl uses
when it appends ", <STDIN> line 1" to a warning or error message.
perldelta for ${^LAST_FH}
fix over/underflow issues in win32_msgwait

This commit does not completely fix 33096, since the real problem is that
VS IDE's debugger causes a Windows message to be sent to perl on each
breakpoint. Depending on where the breakpoint was set. The BP may make it
impossible to exit the loop because of the Visual Studio IDE Debugger's
design. Various overflow and underflow issues were fixed in win32_msgwait.
Specifically, the time count rolling forwards through zero
(GetSystemTimeAsFileTime), and the time count running ahead of the end
time (rolling backwards through zero) were fixed ("<=" check).
Minor fixups from 001e9f8966
update the release schedule

October is now up in the air, probably rjbs.

Dominic is working on 5.14.3
add 5.14.0 sizes and filecounts to perlhist

running and using the output of Porting/perlhist_calculate.pl
has not been done regularly, presumably because I had no idea
that it existed!
add 5.16.0 sizes and filecounts to perlhist

running and using the output of Porting/perlhist_calculate.pl
has not been done regularly, presumably because I had no idea
that it existed!
add Porting/perlhist_calculate.pl to RMG
make perlhist_calculate.pl emit ready-to-use text

format the data for the line in a line (and right now that line matches
up with the lines in the current table)

format the table in a table so that you can block-select it and paste
into the file

the last two edits were done by hand, which was a drag
Add missing articles.
Squash two win32.c warnings which have crept in recently

Ensure a non-void function always returns something, and a signed/unsigned
mismatch.
perlgit: bare ‘git push’ is dangerous

About three times now I have made changes on a branch, to try things
out, and then later on tried to push to blead with ‘git push’ and
modified other people’s branches at the same time.
embed.fnc: Clarify o comments

It applies also to S_ for static functions.
[perl #99382] 'stat' call documentation is poorly worded

The use of "block" to describe both the file-or-device-specific sweet
spot for I/O operations and the number of file-system-specific chunks
(not necessarily 512-byte chunks) is unfortunate.  I think we came by
it honestly because Perl just provides a wrapper around:

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html

which says:

blksize_t st_blksize A file system-specific preferred I/O block size for
                     this object. In some file system types, this may
                     vary from file to file.
blkcnt_t  st_blocks  Number of blocks allocated for this object.

and in the "Rationale" section they say:

"The unit for the st_blocks member of the stat structure is not
defined within IEEE Std 1003.1-2001. In some implementations it is 512
bytes. It may differ on a file system basis. There is no correlation
between values of the st_blocks and st_blksize, and the f_bsize (from
<sys/statvfs.h>) structure members."

The existing piece in perlfunc.pod was written in 1997 for Perl 5.003.
 Screens were smaller then.  Perhaps we could afford to wrap to a
second line now and say something like:
Sync version, erm, version in Maintainers.pl