fix off-by-one when restoring hashes [perl #73972]

Storable tries to preallocate enough space for all of the elements it's
going to receive, both for efficiency reasons and because reallocation
triggers throwing away all of the placeholders in the hash (which are
used for restricted hashes) if the hash isn't already READONLY, and
since Storable rebuilds restricted hashes by first populating all of the
placeholders and then setting it READONLY at the end, this would break
things.

Unfortunately, it was allocating just slightly less than enough space -
hashes reallocate when they hit their limit, not when they exceed it,
and so if you tried to store a restricted hash with a number of keys
right on the boundary, it would trigger a reallocation and lose all of
the allowed keys that it had just stored. This fixes the issue by
allocating the correct amount of space to ensure that reallocation
doesn't happen.
AIX Hints file change

Ok, I think my earlier problem came from not cleaning up properly between
multiple compiles.  So I don't need to modify any test.

Proposed log entry:

When compiling many of the perl modules available from CPAN, an expectation
of C99 support seems implied by many authors.  Unfortunately, xlC doesn't
do this by default, we have to add -qlanglvl=extc99 to the ccflags to get
this to work.  And by the time we get to installing modules, this flag
is already set in Config.

So, add the flag unconditionally at the outset.  Also, remove
-qlonglong and -qlanglvl=extended from the flags to silence the warning that
extc99 includes them and that xlC is going to ignore it, using extc99 instead.

Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
Make srand respect magic

It was returning U+FFFD for negative numbers, but only for non-magical
variables.
Make srand treat "-1" as -1

It was returning U+FFFD for negative numbers, unless they
were strings.

The SvOK is to avoid double uninit warnings.  The !SvIsUV is for
efficiency.  We don’t need to coerce it to an NV if it is a UV
already, because we know it won’t pass that test.
Make pp.c:pp_srand slightly less repetitive
Null HeVAL and local delete → crash

The XS API allows hash entries to be created with null values.  perl
itself uses these internally, too.

Though they should rarely be seen by Perl code, Perl ops should still
be able to handle them without crashing (by croaking).  I fixed helem
and hslice in 5.16 (commit 746f6409), but missed localised deletions.
Squash repetitive code in pp.c:S_delete_local

The two branches of this were almost identical.  Not only is it unnec-
essary to repeat the code, but it is error-prone, as bug fixes have to
be done in both branches.
perldiag: Add cat for ‘Attempt to set length of freed array’
perldiag: ‘Scalars leaked’ is a warning
perldiag: ‘Variable is not imported’ is a default warning
perldiag: ‘Unbalanced scopes’ is a default warning
perldiag: ‘Unbalanced saves’ is a default warning
perldiag: ‘Unbalanced tmps’ is a default warning
perldiag: ‘Unbalanced context’ is a default warning
perldiag: Add cat for PERL_SIGNALS illegal
perldiag: Don’t use L<<>>

diagnostics.pm isn’t smart enough to handle it, and programming it
for one case seems like overkill.
perldiag: ‘invalid option -D%c’ is a warning
perldiag: Add cat for Duplicate modifier
perldiag: ‘Opening dirhandle also as file’ is a default warning
perldiag: ‘Opening fh also as dir’ is a default warning