This change ports pyenv and Python patches to 3.7.12 to enable the
`ctypes `and `decimal` modules to compile.

While Python 3.7.12 itself compiles on arm64/M1, both of these modules
fail to compile, due to missing support for locating system libffi and
due to architecture gate-keeping. These issues have been fixed in newer
releases of Python, and in other pyenv patch bundles.

The following patches are provided:

1. `0001-Port-ctypes-and-system-libffi-patches-for-arm64-macO.patch` -
   Fixes system `ffi.h`/`libffi` path determination and usage and
   enables calling of variadic functions, fixing ctypes support
   (consolidated port of existing pyenv patches for 2.7.18 that iterate
   on this logic).

2. `0002-bpo-41100-fix-_decimal-for-arm64-Mac-OS-GH-21228.patch` -
   Adds arm64 to the list of allowable architectures for the
   `decimal` module (port of Python patch introduced in 3.8.10).

This change ports several established patches to the Python 3.6.15
build, enabling compilation on arm64/Apple M1 architectures:

1. `0001-Detect-arm64-in-configure.patch` -
   Updates configure to detect arm64 architectures (port of an existing
   pyenv patch for 2.7.18).

2. `0002-bpo-36231-Support-building-on-macOS-without-usr-incl.patch` -
   Adds macOS SDK root computation logic for determining include paths
   (port of existing Python patches introduced in 2.7.17 and 3.7.4).

3. `0003-Fix-macOS-_tkinter-use-of-Tck-Tk-in-Library-Framewor.patch` -
   Fixes Tcl/Tk support on macOS (port of an existing pyenv patch
   for 2.7.18).

4. `0004-Port-ctypes-and-system-libffi-patches-for-arm64-macO.patch` -
   Fixes system `ffi.h`/`libffi` path determination and usage and
   enables calling of variadic functions, fixing ctypes support
   (consolidated port of existing pyenv patches for 2.7.18 that iterate
   on this logic).

5. `0005-BPO-41100-Support-macOS-11-when-building-GH-21113.patch` -
   Updates Darwin version checks to handle macOS 11's major version
   bump (port of Python patches introduced in 3.7.0 and 3.9.0).

6. `0006-bpo-41100-fix-_decimal-for-arm64-Mac-OS-GH-21228.patch` -
   Adds arm64 to the list of allowable architectures for the
   `decimal` module (port of Python patch introduced in 3.8.10).

* Use verify_py39 since anaconda3-2021.11 is using python-3.9 according to release notes

[source](https://www.anaconda.com/blog/anaconda-individual-edition-2021-11#:~:text=Update%20on%20macOS%20Apple%20M1%20Support)

`which` has been deprecated in Debian's debianutils 5.0+
They suggest using `type` and `command` as replacements:
3a8dd10b45 ,
610a65c6ef

* Fix "PKG_PROG_PKG_CONFIG: command not found"

Apply f146ca36f8
* bpo-45350: Rerun autoreconf with the pkg-config macros (GH-28707)

This is needed to find other Python deps (e.g. libintl) in Homebrew if it has
nonstandard prefix (e.g. in Apple M1)

* Re-allow to search Homebrew for zlib everywhere

Don't override a user-supplied value

Link to the active version like other Homebrew deps --
this won't break when another binary-compatible version is installed.
Use a discovery method that doesn't break when other versions are present alongside.

Fix typo `ase` -> `case`

This one gets rid of the extra "usr" subdirectory that we had and now fits the format that pyenv expects

We changed the directory structure for pyston 2.3.1 slightly, where we now
include a top-level "pyston-2.3.1" directory when you unpack the tarball.

Required to prevent a crash when no verbosity given.

* feat(python-build): allow tcl-tk as argument or default to homebrew
* refactor(python-build): detect tcl-tk-libs from confugre_opts_arr

* Disable coreutils on arm64-apple
* Only selectively apply to the affected CPython versions

Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>

This is essentially the same fix as in pull request #2047, but it
is applied from Python 2.6.6 to 2.6.9, and for `ossaudiodev` as well
as the (deprecated) `linuxaudiodev`.

With the normal `setup.py`, the installation of the `ossaudiodev`
module is skipped under GNU/Linux with newer kernel versions because
Python 3.1 appends the major kernel version to the result of
`build_ext.get_platform` and later `ossaudiodev` is skipped if the
major kernel version is not 2. A similar problem might occur if
installing in FreeBSD.

This problem may even occur if installing Python 3.1 in a Docker image
of an old OS (e.g. prehistoric Debian or CentOS), because the major
kernel version is still the one of the host system.

The solution is to use `str.startswith` and only check that the
platform starts with 'linux' or 'freebsd'.