Fix regex seqfault 5.18 regression

This segfault is a result of an optimization that can leave the
compilation in an inconsistent state.

  /f{0}/

doesn't match anything, and hence should be removable from the regex for
all f.  However,

  qr{(?&foo){0}(?<foo>)}

caused a segfault.  What was happening prior to this commit is that
(?&foo) refers to a named capture group further along in the regex.
The "{0}" caused the "(?&foo)" to be discarded prior to setting up the
pointers between the two related subexpressions; a segfault follows.

This commit removes the optimization, and should be suitable for a
maintenance release.

One might think that no one would be writing code like this, but this
example was distilled from machine-generated code in Regexp::Grammars.

Perhaps this optimization can be done, but the location I chose for
checking it was during parsing, which turns out to be premature.  It
would be better to do it in the optimization phase of regex compilation.
Another option would be to retain it where it was, but for it to operate
only on a limited set of nodes, such as EXACTish, which would have no
unintended consequences.  But that is for looking at in the future; the
important thing is to have a simple patch suitable for fixing this
regression in a maintenance release.

For the record, the code being reverted was mistakenly added by me in
commit 3018b823898645e44b8c37c70ac5c6302b031381, and wasn't even
mentioned in that commit message.  It should have had its own commit.
Avoid needless refcount and mortialization on pp_anonhash

pp_anonhash can be used to construct both bare hashes and hashrefs. In
the hashref case, it used to create an HV and mortalize it. Then it went
through the parameters on the stack and copied them into the hashref.
This can throw exceptions which would make the HV leak if it hadn't been
mortalized.

After potentially copying the arguments, pp_anonhash would then in the
hashREF case increment the refcount on the HV *again*, create an RV for
the HV, and mortalize that RV before pushing it on the stack.

Instead, we can get away with constructing the HV and only mortalizing
it if there's no mortalizable ref to clean up if there's an exception.
This should remove a fair fraction of work in the common case of empty {}
hash ref construction.
Fix to make 8d455b9f99c1046e969462419b0eb5b8bf740a47 not a lie

Previous commit 8d455b9f99c1046e969462419b0eb5b8bf740a47 was a partial
lie. This commit fixes it up not to be a lie and to avoid mortalizing
the HV.
Make perlbug look up the list of local patches at run time

Re-parsing patchlevel.h in Perl by perlbug.PL is error prone
and apparently unnecessary. The same information is available
to perlbug via Config::local_patches().

This fixes [perl #118433].
perldelta for c448c12411b1ba
dist/lib/Makefile.PL: change INSTALLDIRS to 'site' for 5.12 and later
#118675 fix 4 porting/pod_rules.t uses different perl than compiled one

See rt ticket #118675 for background on this patch.
Patches must not be sent via git's format-patch/send-email

updated to match perlgit.pod
S_strip_spaces doesn't need to be seen out of core
Branch predictor hints: exists is mostly run on hashes
OP*method was added in c106c2be8b83ee but never used
Trim the explicit Makefile rules to generate {mini,}perlmain.o

These duplicate the suffix rules used for general .c -> .o compilation.
makedepend automatically generates a dependency for miniperlmain.o on
patchlevel.h
Remove Configure code that supported the old-style nested layout for ext/

5.10.1 switched to the new layout, so this code would only be useful for
backporting to maint-5.8. That isn't going happen, so it can go.
Add non-XS extensions to known_extensions.

Previously "known_extensions" was misnamed, as it only contained known XS
extensions. grep.cpan.me suggests that there are only 10 mentions of it
outside the core, and none of them rely on this existing behaviour.

Update the descriptions of extensions, known_extensions and nonxs_ext in
Porting/Glossary.

These changes need replicating into configure.com.
Also add Encode's sub-modules to known_extensions when building statically.

There is code in Configure to treat Encode specially when it is specified as
a statically linked extension. By default, Encode builds separated shared
objects for each of its subdirectories. This works well with DynaLoader,
and the top level perl Makefile doesn't even notice this, because it doesn't
have to list these libraries as things it links with at compile time.

For a static link, Encode builds a separate *.a file for each of its
subdirectories. The top level Makefile *does* need to know about these, as
a static link requires them all to be listed. Hence the work-around is to
treat Encode as a set of nested modules if linked statically.

We can't do this in Makefile.SH because the various Encode submodules are
installed as separate *.a files in the tree, and so need to continue to be
treated as distinct modules in case ExtUtils::MakeMaker is asked to (re)link
a static perl with an additional extension.

I suspect that the most elegant fix would be to tweak Encode's top level
Makefile.PL to link everything into one *.a if it is building statically.
I'm not sure how to do that, and it would need to be accepted upstream.
In FindExt, eliminate _ext_ne() and make extensions() a simple subroutine.

Previously _ext_ne() was a generator function, and extensions() and
known_extensions() were generated by it. Now that known_extensions() has a
different implementation, extensions() was the last user of _ext_ne(), so
there's no saving by keeping the complexity.
Correct a type in FindExt::apply_config in the "I18N-Langinfo" code.

Commit 557ab4cb986767c7 (Feb 2011) which added this routine had
$config->{i_nl_langinfo} not $config->{d_nl_langinfo} ('i' should be 'd').

The logic for I18N::Langinfo should now be correct.
Thanks to FindExt::apply_config() we're now able to test dynamic extensions.

FindExt::apply_config() mimic's Configure's logic, which means that FindExt's
idea of which extensions should be built is consistent with Configure's.
Minor refactors to FindExt's test, removing code duplication.

Use a ternary instead of if/unless on the same $^O test.
Use a loop to call FindExt::scan_ext()
As FindExt exports nothing, we can require it rather than using it.
In FindExt.t, move the main loop's comparison logic into a subroutine.