Part of the PEP 730 work to add iOS support.

This PR adds the iOS targets to configure and Makefile to support compiling an iOS framework. It doesnot include the test harness and related targets that was included in#115063 - that will come in a follow up PR.

This PR slightly containsone deviation from PEP 730, as it uses the<cpu>-<abi> format for PLATFORM_TRIPLE and _PYTHON_HOST_PLATFORM, rather than<abi>-<cpu> (i.e., it usesarm64-iphoneos, notiphoneos-arm64). This was identified during the review of#115120 as an inconsistency with the ordering of existing platform triples. This is an almost entirely cosmetic change with no compatibility considerations, as the only impact is the final naming scheme ofsysconfig modules and thesys.implementation._multiarch attribute.

As of this PR, it is now possible tocompile an iOS framework; but the framework still isn't usable at runtime.

Summary of changes

• Patchesconfig.sub to include 2 modifications required to support iOS/tvOS/watchOS builds (supporting the arm64_32 CPU identifier, and the-simulator suffix). These were submitted upstream as part of a patch in August last year, but that patch was only partially applied. The autoconf contribution process is opaque, and no feedback was given on why the other parts were rejected (there wasn't even feedback that they'd been partially accepted - I discovered that by accident). The extra pieces have been re-submitted upstream.
• Modifies the internal target name for setting up a versioned macOS framework, and adds a set of targets for an unversioned iOS-style framework. See below for details on iOS framework structure.
• Adds the flags to build iOS-compatible binary modules linked against the Python framework
• Presumptively adds the arm64 device and simulator targets to the Tier 3 support list. Getting anx86_64 buildbot is proving difficult because of hardware availability, so I've omitted that target from Tier 3.This possibility was flagged in PEP 730.
• Skips the automated detection of a couple of system functions where autoconf gets the answer wrong - autoconf only checks whether a symbol can be linked, and doesn't use header files; iOS headers raise warnings when some symbols are used. There are also methods that exist and can be compiled, but raise errors if used at runtime.
• Automatically skips the configuration of ac_cv_file__dev_ptmx and ac_cv_file__dev_ptc, which are usually mandatory command line arguments for cross-platform builds. iOS is a reliable cross-build target, so we know these features aren't available.
• Adds an iOS resources folder that contains template files and stub binaries. See below for a discussion about the stub binaries. Internal documentation for building the iOS framework has been added; user-facing docs will be added in a future PR.
• Includes apyconfig.h file that can be used to switch between CPU-dependent pyconfig.h files.
• Disables the standard library modules that aren't available on iOS.
• Doesn't include an tvOS and watchOS targets or resources. These will be submitted independently.

Differences between macOS and iOS Frameworks

iOS frameworks are slightly different to macOS frameworks.

• macOS frameworks are "multi-version", as they are designed to support having multiple framework versions in a single Framework folder. iOS frameworks can't be shared between apps, so they don't support "multi-version" format.
• The metadata required by Info.plist is slightly different, and must be in the root of the framework, not a Resources subfolder.
• The install name for the library in the framework must be based on an @rpath, rather than an absolute path, as the install path for the framework will be app-specific.
• iOS frameworks can only include binary .dylib artefacts and headers; and the headers won't be copied into the final distribution binary. As a result, the standard library and support binaries cannot be distributed inside the framework - they must be distributed parallel to the Framework folder.

To accomodate these difference, the make install target for iOS will generate a file structure like the following:

(--enable-framework location)

• bin
• include symlink to -> Python.framework/Headers
• lib
  • python3.X
    • ...
• Python.framework
  • Headers
    • ...
  • Python (the dylib binary)
  • Info.plist

The task of copying the standard library into an appropriate location in the final app bundle is left as a task for the developer using the framework.

Stub binaries

Xcode doesn't expose explicit compilers for iOS/tvOS/watchOS; instead, it uses an xcrun script that resolves to a full compiler path (e.g., xcrun --sdk iphoneos clang to get the clang for an iPhone device). However, using this script poses 2 problems:

• The output of xcrun includes paths that are then machine specific, resulting in a sysconfig module that cannot be shared between users
• It results in CC/CPP/LD/AR definitions that include spaces. There is a lot of C ecosystem tooling (including distutils and setuptools) that assumes that you can split a command line at the first space to get the path to the compiler executable; this isn't the case when using xcrun.

To avoid these problems, the iOS/Resources/bin folder includes shell script wrappers around the tools needed by configure, named using the scheme that autoconf expects by default. These scripts are relocatable, and will always resolve to the appropriate local system paths. By including these scripts in the "installed" bin folder, the contents of the sysconfig module becomes useful for end-users to compile their own modules.

• Issue:Add support for iOS as a target platform #114099