layout: restructure into src/ tests/ android/ scripts/ tools/

- extension/src/{port,platform,codepage} -> src/; native_render -> src/host
  (+ dxt, shaders/); libgr2 -> src/gr2; extension/third_party -> third_party
- extension/tests -> tests/port, libgr2/tests -> tests/gr2
- android-native -> android (build.sh, push-client.sh moved in)
- script -> scripts; tools/40250 -> tools/server; oracle -> tools/granny-oracle;
  perf tools -> tools/perf
- all build trees under build/ (native, release, android, port-gate)
- xrender:: CMake aliases -> mt::; port-map ledger impl paths rewritten

No code changes. ctest 15/15, port_gate macos+android PASS, port_map check 0 errors.

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

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.