Use SSize_t for tmps stack offsets

This is a partial fix for #119161.

On 64-bit platforms, I32 is too small to hold offsets into a stack
that can grow larger than I32_MAX.  What happens is the offsets can
wrap so we end up referencing and modifying elements with negative
indices, corrupting memory, and causing crashes.

With this commit, ()=1..1000000000000 stops crashing immediately.
Instead, it gobbles up all your memory first, and then, if your com-
puter still survives, crashes.  The second crash happesn bcause of
a similar bug with the argument stack, which the next commit will
take care of.
Use SSize_t when extending the stack

(I am referring to what is usually known simply as The Stack.)

This partially fixes #119161.

By casting the argument to int, we can end up truncating/wrapping
it on 64-bit systems, so EXTEND(SP, 2147483648) translates into
EXTEND(SP, -1), which does not extend the stack at all.  Then writing
to the stack in code like ()=1..1000000000000 goes past the end of
allocated memory and crashes.

I can’t really write a test for this, since instead of crashing it
will use more memory than I have available (and then I’ll start for-
getting things).
Croak when range tries to extend stack too far

This fixes the rest of ticket #119161.

The range operator uses IVs internally to hold the current value for
integer ranges.  It already checks that the arguments are within the
IV range and croaks otherwise.  However, on 32-bit platforms with
64-bit integers, the different between the range’s endpoints can
exceed the maximum allowed memory allocation.  This resulted in a
crash for 1..2**31, because EXTEND was passed a value which, when
cast to SSize_t, became -1, resulting in no reallocation.  Then
pp_flop proceeded to write past the end of the stack.

No tests are included in this commit, as 1..2**31 could give three
different results depending on the platform.
Use SSize_t for arrays

Make the array interface 64-bit safe by using SSize_t instead of I32
for array indices.

This is based on a patch by Chip Salzenberg.

This completes what the previous commit began when it changed
av_extend.
Stifle diag.t

Maybe we should extend it at some point to run things through
splain and see whether there is a match.
Increase $Data::Dumper::VERSION to 2.149
Increase $Math::BigInt::FastCalc::VERSION to 0.31
Increase $mro::VERSION to 1.14
pp_ctl.c:pp_flop: Avoid redundant SvNV calls

Calling SvNV on an SV that is IOK is unnecessary, and results in an
extra function call if the SV is not NOKp.  If an NV is out of range
and has been used as an int, it will be IOKp but not IOK.