-this fatal error is much more common by general users than
 I (orig author) anticipated when I added this check in 5.21.6/2014.
 I assumed Unix land never had ABI/SEGVing or upgrade problems previous.
 I wrote the code for my dev style, and my personal setup as test cases,
 and test cases with Win32-isms.
 If other OSes get bad-ABI caught, its a plus, but I thought they wouldn't.

-the hexadecimal handshake keys were intended to be a debug tool for core
 devs hacking on something and for XS authors with very complicated
 Makefile.PL s. To catch -D CCFLAGS arg dropouts on the way to the final
 cmd line invocation of the CC.

-I say the handshake keys are a terrible UI for general "power users" and
 non-coder sys admins

-the Perl API version strings ARE available, even with mismatched
 interp struct sizes, and those are much more user friendly to print
 as a error. It should be obvious that from now on, non-power users
 can figure out on their own (no community help) that a way to "fix"
 XS boot handshake is to force "reinstall" the "left side perl"
 or "right side perl" through the OS Pkg Manager.

-after this commit, much more often! but not always, users will see a
 "Perl API 5.X.Y against 5.X+1.Y is incompatible" fatal message instead
 of the those Core-dev only undocumented hex handshake keys. Sadly the
 technical P5P debug info is now gone/lost/hidden if
 "Perl API 5.X.Y against 5.X+1.Y is incompatible" fatal message executes.

-core devs, obv will have v5.X.Y matching v5.X.Y in blead perl, so they
 will still get the handshake keys hex numbers. Since API strings are
 same.

-Package name will get downgraded to "Foo.c" if interp size is wrong, or
 2 libperls in 1 proc happens. But the major improvement is showing left
 and right side Perl API version info.

-The POD text is very wordy and detailed, since it has been observed over
 time, some Perl users, do not know Perl's backend implementation is
 written in the ISO C language. Or other Perl users on various internet
 forums or social media, do not know what the term XS code is.

 While they can sucessful write and debug private personal Perl 5 code,
 they only read the POD of CPAN modules and only use public documented
 APIs of CPAN modules, and rarely or never look at
 "private source" of CPAN modules. Therefore this group of users truly
 do not know MANY MANY p5p core modules and CPAN modules, make call outs
 to another language (C), and are unable to troubleshoot a .so file on
 their filing system is responsible for the error. Since they do not know
 about XS code concept, their troubleshooting goes very wrong as they
 keeping looking and keep incorrect diagnosing the problem to ASCII text
 somewhere in the Perl ecosystem. Either Perl source code, they wrote, or
 CPAN Perl source code, or a CSV, YAML or JSON file related to Perl.

 Make it clear, that some "Perl 5 modules" written in ASCII text in Perl 5
 lang, depend on "foreign" C code and "foreign" .so/.dll files at runtime.
 First time Perl coders, can mistakenly assume the Perl 5 interpreter
 has JIT and self bootstraps to OS binaries from only Perl 5 source like
 Google Chrome V8 and Raku. So they guess, as first time users,
 Perl 5 also does it and has no dependency on legacy technologies like
 C or C++.

This commit was specifically written for

Perl#16654

but there are dozens or 100s of them

Perl#19112