Undiamond Python headers

This change gets the Python codebase into a state where it conforms to
the conventions of this codebase. It's now possible to include headers
from Python, without worrying about ordering. Python has traditionally
solved that problem by "diamonding" everything in Python.h, but that's
problematic since it means any change to any Python header invalidates
all the build artifacts. Lastly it makes tooling not work. Since it is
hard to explain to Emacs when I press C-c C-h to add an import line it
shouldn't add the header that actually defines the symbol, and instead
do follow the nonstandard Python convention.

Progress has been made on letting Python load source code from the zip
executable structure via the standard C library APIs. System calss now
recognizes zip!FILENAME alternative URIs as equivalent to zip:FILENAME
since Python uses colon as its delimiter.

Some progress has been made on embedding the notice license terms into
the Python object code. This is easier said than done since Python has
an extremely complicated ownership story.

- Some termios APIs have been added
- Implement rewinddir() dirstream API
- GetCpuCount() API added to Cosmopolitan Libc
- More bugs in Cosmopolitan Libc have been fixed
- zipobj.com now has flags for mangling the path
- Fixed bug a priori with sendfile() on certain BSDs
- Polyfill F_DUPFD and F_DUPFD_CLOEXEC across platforms
- FIOCLEX / FIONCLEX now polyfilled for fast O_CLOEXEC changes
- APE now supports a hybrid solution to no-self-modify for builds
- Many BSD-only magnums added, e.g. O_SEARCH, O_SHLOCK, SF_NODISKIO

third_party/python/Modules/expat/pyexpatns.h

@@ -1,43 +1,6 @@
-/* clang-format off */
-/* Copyright (c) 2005-2006 ActiveState Software Inc.
- *
- * Namespace all expat exported symbols to avoid dynamic loading symbol
- * collisions when embedding Python.
- *
- * The Problem:
- * - you embed Python in some app
- * - the app dynamically loads libexpat of version X
- * - the embedded Python imports pyexpat (which was built against
- *   libexpat version X+n)
- * --> pyexpat gets the expat symbols from the already loaded and *older*
- *     libexpat: crash (Specifically the crash we observed was in
- *     getting an old XML_ErrorString (from xmlparse.c) and then calling
- *     it with newer values in the XML_Error enum:
- *
- *       // pyexpat.c, line 1970
- *       ...
- *       // Added in Expat 1.95.7.
- *       MYCONST(XML_ERROR_UNBOUND_PREFIX);
- *       ...
- *
- *
- * The Solution:
- * Prefix all exported symbols with "PyExpat_". This is similar to
- * what Mozilla does for some common libs:
- * http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115
- *
- * The list of relevant exported symbols can be had with this command:
- * 
-       nm pyexpat.so \
-           | grep -v " [a-zBUA] " \
-           | grep -v "_fini\|_init\|initpyexpat"
- *
- * If any of those symbols are NOT prefixed with "PyExpat_" then
- * a #define should be added for it here.
- */
-
 #ifndef PYEXPATNS_H
 #define PYEXPATNS_H
+/* clang-format off */
 
 #define XML_DefaultCurrent              PyExpat_XML_DefaultCurrent
 #define XML_ErrorString                 PyExpat_XML_ErrorString
@@ -121,6 +84,4 @@
 #define XmlUtf16Encode                  PyExpat_XmlUtf16Encode
 #define XmlUtf8Encode                   PyExpat_XmlUtf8Encode
 
-
 #endif /* !PYEXPATNS_H */
-