Cloning a format whose outside has been undefined

This has crashed ever since 71f882da8, because the format tries to
close over a pad that does not exist:

sub x {
    {my ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m,$n,$o,$p,$q,$r,$s,$t,$u)}
    my $z;
    format =
@<<<
$z
.
}
undef &x;
write;

This commit adds checks for nonexistent pads, producing the ‘Variable
is not available’ warning in cases like this.
Fix up pod references to deprecated function
[rt.cpan.org #61577] sockdomain and socktype undef on newly accepted sockets

There appears to be a flaw in IO::Socket where some IO::Socket objects
are unable to properly report their socktype, sockdomain, or protocol
(they return undef, even when the underlying socket is sufficiently
initialized to have these properties).

The attached patch should cover IO::Socket objects created via accept(),
new_from_fd(), new(), and anywhere else whose details haven't been
properly cached.

No new code should be executed on IO::Socket objects whose details are
already cached and present.

These tests were original written by Daniel Kahn Gillmor
<dkg@fifthhorseman.net>, I've mangled them for use in a hopefully
final fix for the issue.
[rt.cpan.org #61577] propagate socket details on accept
[rt.cpan.org #61577] try to populate socket info when not cached

The fixes are originally by Daniel Kahn Gillmor
<dkg@fifthhorseman.net>, but I've made other changes.
document the limitations of protocol(), sockdomain(), socktype()

Determining these for a new_from_fd() socket has the following problems:

protocol() depends on SO_PROTOCOL, and socktype() on SO_TYPE, not
implemented on all systems.

sockdomain() depends on sockname(), which is documented as
unimplemented for AF_UNIX sockets on HP-UX.

I'm not sure that detail is useful in the documentation.
bump IO::Socket version
add Test::More as a prereq to Makefile.PL
bump IO.pm version

cmpVERSION doesn't pick this up - should it?
perldelta for 18042359, 9adbac0b
s/thinngy/thingy/ in a comment in sv.c
Use find_runcv_where for pp_coreargs and pp_runcv
Put a cap on op slab sizes

If a subroutine is *really* big, we don’t want to allocate, say, 4MB
for ops when just over 2 will do, just because there was one op more
than could fit in 2MB.
pad.c: Improve intro_my docs
fix 64-bit compiler warning
Fix ill-named Test::Harness test and bump version.

env.opts.t by its very existence causes the test suite to die on
VMS with:

$ perl TEST ../cpan/Test-Harness/t/compat/env.opts.t
Can't read ../cpan/test-harness/t/compat/env.opts.t.
%RMS-F-SYN, file specification syntax error

Enabling the extended filename character set will fix this but that's
not (yet) the default setting.  So here we simply rename the file to
something legal.

Reported upstream as [rt.cpan.org #78127].
op.c:newFOROP: Fall back to realloc for unslabbed ops

When an op is allocated, PL_compcv is checked to see whether it can
hold an op slab if it does not hold one already.  If PL_compcv is not
usable, for whatever reason, it falls back to malloc.

Since the new slab allocator was added in commit 8be227a, newFOROP has
been assuming, probably correctly, that its listop which it needs to
enlarge to a loopop was allocated by slab.

Since newFOROP is an API function, we should err on the safe side and
check first whether the op is slab-allocated, falling back to realloc
if it is not.

To trigger this potential bug, one has to set things up such that
there is a usable pad available, but no usable PL_compcv.  I said
‘probably correctly’ above because this situation is highly unlikely
and probably indicative of bugs elsewhere.  (But we should still err
on the side of safety.)
perlfunc: Fix do-sub mistake

do &foo() is the do-file operator on the return value of the sub,
not just a sub call.
For #16249 - Overwrite PL_last_lop_op when eval() is called.

Otherwise, parsing later on down the road may use the previous value, which, if it was OP_PRINT, causes the parser to fail
toke.c: Merge UNI2 and UNIBRACK

The only difference between them is the PL_expect assignment,
which can be controlled by a constant parameter that the C
compiler will optimise away.