ExtUtils::ParseXS version bump to 3.21
EU::Typemaps: Implement API for typemap cloning

The docs used to suggest cloning, but never provided an API.
EU::ParseXS: Only initialize some parser regexps once
EU::ParseXS: Don't inherit from Exporter; import 'import' instead
EU::ParseXS: Stop using global state; an OO interface

This stops ExtUtils::ParseXS from using global state (unless using the
functional interface which uses a singleton for compatibility). It also
makes the interface more or less properly OO.

Includes tests & docs; migrates xsubpp to use the OO interface.
EU::Typemaps: Document special typemap variables

For better or for worse, these are likely to stay. Don't cry if they
don't.
EU::ParseXS: Update Changelog
EU::ParseXS: Attempt to canonicalize C++ types in tidy_type

Includes moving tidy_type to ExtUtils::Typemaps where it seems to
belong. It's a pretty poor canonicalizer, but better than nothing!
EU::ParseXS: Update changelog
EU::ParseXS: Drop dup'd code: make_targetable moves to EU::Typemaps

The make_targetable function in ExtUtils::ParseXS::Utilities now lives
in ExtUtils::Typemaps::OutputMap as method 'targetable' since the code
was quite duplicated before. Makes very minor adjustments to
'targetable'.

Removes the flawed make_targetable tests. Improved tests in lieu of the
old ones will be added asap.
EU::ParseXS: Fix targetable size detection

Adds new / vastly improved tests for 'targetable'.
Also improves targetable documentation.
EU::ParseXS: Cosmetics; better variable naming
EU::ParseXS: Simplify output typemap code generation (targetable)
EU::ParseXS: Use OO version of ExtUtils::ParseXS in test

Sort of. Breaking encapsulation, but that's better than not even having
a blessed object at all.
EU::ParseXS: Cosmetics; more explicitness in *_handler

Basically, using named lexical beats $_ by a long shot since they don't
magically propagate into functions called.
EU::ParseXS: Move several constants out of the runtime object
EU::ParseXS: Test cleanup

Lots of dead code and some inflexibilities wrt. running tests from / or
t/.
Stop "sv_2mortal(&PL_sv_yes)" and "(void)sv_newmortal()" in ParseXS

This problem was brought up in #115796.  Both of those lines of code that
ParseXS put out when dealing with T_BOOL were unnecessary, and caused a
some inefficiencies (extra calls). Since typemaps can have complicated
evaluation and include Perl code, see commit    9712754a3e, it is best to
eval the typemap entry first, then regexp it to see what it looks like,
not regexp the unevaled entry possibly containing Perl. In case a typemap
entry is maintaining state inside ParseXS (venturing into the undocumented
and unsupported), (I've never seen it done) don't eval it twice if it can
be avoided. Someone might want to change the typemap entry to multiple
eval in the future, but don't introduce it now if it can be avoided.

Using T_BOOL by name to see an immortal is a bad idea, since any XS module
can reuse the typemap entry, so best to regexp for something that looks
like it would return an immortal, "= &PL_sv_* ;" or "= boolSV(". In the
future someone might want to introduce a macro that does nothing, except
gives a signal to ParseXS that an expression returns an immortal or an
already mortaled SV, to suppress the sv_2mortal call.

The tests in 001-basic.t might break in the future with changes to ParseXS
or the Perl API, but I assume they will be fixed at that point in time.

Note: This patch was amended by the committer to apply cleanly to a
newer version of ExtUtils::ParseXS and to include all necessary test
changes.
Document and clean up -s option to xsubpp

At the same time, discourage its use. It's an obscure option that, most
of the time, does the opposite of what people actually need. If nothing
else, it should be a feature of XS instead of xsubpp.

But it exists, so documenting it with a warning is the right thing to
do.