port 2P step 1: vendor CPython 2.7.18 as the mtpython static library

The embedded 40250 script layer needs its own interpreter on five platforms.
2.7 is end-of-life, so nothing can be fetched from the target SDKs and the
source is vendored (official 2.7.18 tarball, trimmed to 25MB; Lib/ stays for
step 3's python27.zip).

cpython-2.7.18/CMakeLists.txt builds one `mtpython` static library from exactly
the 133 objects the reference libpython2.7.a contains, off by default behind
-DMTGODOT_EMBED_PYTHON=ON. The source list and the built-in module table
(config/config.c, 39 entries) are shared; pyconfig.h is a probe result and is
not, so each platform keeps its own under config/<platform>/, regenerated by
tools/py_embed/gen_pyconfig.sh and checked against the shared table.

Three vendor patches, documented in docs/THIRD-PARTY.md: configure/configure.ac
learn arm64 on macOS, and posixmodule.c undefines the process-control calls it
hard-defines past pyconfig.h when building for iOS.

macOS (ctest python.embed: every builtin imports, codecs and pickle work off the
vendored Lib/), Android arm64 and iOS arm64 build. Linux needs a Linux host and
Windows needs a MinGW-vs-MSVC decision; both are noted for step 4.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

extension/third_party/cpython-2.7.18/Misc/Porting

@@ -0,0 +1,41 @@
+Q. I want to port Python to a new platform.  How do I begin?
+
+A. I guess the two things to start with is to familiarize yourself
+with are the development system for your target platform and the
+generic build process for Python.  Make sure you can compile and run a
+simple hello-world program on your target platform.  Make sure you can
+compile and run the Python interpreter on a platform to which it has
+already been ported (preferably Unix, but Mac or Windows will do,
+too).
+
+I also would never start something like this without at least
+medium-level understanding of your target platform (i.e. how it is
+generally used, how to write platform specific apps etc.) and Python
+(or else you'll never know how to test the results).
+
+The build process for Python, in particular the Makefiles in the
+source distribution, will give you a hint on which files to compile
+for Python.  Not all source files are relevant -- some are platform
+specific, others are only used in emergencies (e.g. getopt.c).  The
+Makefiles tell the story.
+
+You'll also need a pyconfig.h file tailored for your platform.  You can
+start with pyconfig.h.in, read the comments and turn on definitions that
+apply to your platform.
+
+And you'll need a config.c file, which lists the built-in modules you
+support.  Start with Modules/config.c.in.
+
+Finally, you'll run into some things that aren't supported on your
+target platform.  Forget about the posix module for now -- simply take 
+it out of the config.c file.
+
+Bang on it until you get a >>> prompt.  (You may have to disable the
+importing of "site.py" by passing the -S option.)
+
+Then bang on it until it executes very simple Python statements.
+
+Now bang on it some more.  At some point you'll want to use the os
+module; this is the time to start thinking about what to do with the
+posix module.  It's okay to simply #ifdef out those functions that
+cause problems; the remaining ones will be quite useful.