Fix assertion failure/hang with / (?{(^{})/

When this invalid construct is parsed, the resulting op tree for the
pattern has a code block with no constant item following it, breaking
the assumptions made by pmruntime.

Fixing this was not so easy.

You can’t just adjust the assertions, because the hang that non-debug-
ging builds exhibited is still there.

You can’t just return NULL from pmruntime when encounting the bad op
tree, because the parser will crash on the null pointer.

You can’t just return the empty pmop, because the wrong pad is
active, and other functions in op.c will try to access nonexistent
pad entries.

You can’t just LEAVE_SCOPE and return the pmop, because then PL_parser
will be null in yyerror.  Changing yyerror to account is not suffi-
cient, because then you get double-freed SVs.  At that point I gave up
with that approach.

The easiest solution turned out to be to fake up the op that we were
expecting to see.
regcomp.c: Compiler warning

Shut up this warning:

regcomp.c:7346:13: warning: format specifies type 'unsigned long' but the
      argument has type 'U32' (aka 'unsigned int') [-Wformat]
            RExC_study_chunk_recursed_count);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by casting to auld lang syne—I mean unsigned long.
optimize SV creation funcs in sv.c

In Perl_newSV, the sv_upgrade is redundant, except to protect against a
segv in blindly SV body derefing SvGROW (but not in sv_grow). sv_grow has
always upgraded a non-PV SV to PV. So don't it here. Since a new SV will
never have be a COW, have a SvLEN or a body, all of which SvGROW uses,
just call sv_grow. Less branching, and smaller code that way.

In Perl_newSV_type, give a hint to compiler that if a platform's
symbol visibility allows inlining, and newSV_type's arg is the base type
(currently SVt_NULL, maybe SVt_IV in future (see ML)), to possibly inline
new_SV into the caller and remove the sv_upgrade call. Also don't call
sv_upgrade if it isn't needed (SVt_NULL) in the public symbol version.

The redundant sv_upgrade then sv_grow goes to commit 79072805bf
"perl 5.0 alpha 2". VC 2003 -01 32 bit threaded machine code size in bytes
of 2 functions
Perl_newSV_type before 0x2f after 0x29
Perl_newSV  before 0x48 after 0x28
silence compiler warnings in utf8_mg_pos_cache_update

commit 73ecc8cb69 added warnings on VC2003, silence them
..\sv.c(7556) : warning C4244: '=' : conversion from 'STRLEN' to 'float', possible loss of data
..\sv.c(7557) : warning C4244: '=' : conversion from 'const STRLEN' to 'float', possible loss of data
..\sv.c(7560) : warning C4244: '=' : conversion from 'const STRLEN' to 'float', possible loss of data
..\sv.c(7561) : warning C4244: '=' : conversion from 'STRLEN' to 'float', possible loss of data
clarify use VERSION docs

Anything that C<use VERSION> adds, another C<use VERSION> may take away.
Explicitly doing the C<use strict> and/or C<use feature> means that
C<use VERSION> will not change them. C<use VERSION> will only change
the defaults, or things done by C<use VERSION>.
Consistent spaces after dots in perlfunc