Binary build script: Switch from timestamp to hash based .pyc files

[edmorley]

When we build Python binaries, the make install step automatically generates .pyc files for the Python stdlib, however:

• It generates these using the default timestamp invalidation mode, which does not work well with the CNB file timestamp normalisation behaviour.
• It generates .pycs for all three optimisation levels (standard, -O and -OO), when the vast majority of apps only use the standard mode.

As such, this changes our builds to:

• Use one of the hash-based pyc invalidation modes to prevent the .pycs from always being treated as outdated and so being regenerated at application boot.
• Ship only the standard optimisation level pycs (and not the .opt-{1,2}.pyc files), reducing build output by 18MB.

We use the unchecked-hash mode rather than checked-hash since it improves app startup times by ~5%, and is only an issue if manual edits are made to the stdlib, which is not something we support.

See:
https://docs.python.org/3/reference/import.html#cached-bytecode-invalidation
https://docs.python.org/3/library/compileall.html
https://peps.python.org/pep-0488/
https://peps.python.org/pep-0552/
https://github.com/python/cpython/blob/v3.10.4/Makefile.pre.in#L1603-L1629

GUS-W-10988998.
GUS-W-10989125.

[edmorley]

The combined build output size reductions from this PR plus #1319, #1320 and #1321, are:

• Python 3.10:
  • Uncompressed: 207 MB -> 38 MB
  • Compressed: 51 MB -> 13 MB
• Python 3.9:
  • Uncompressed: 196 MB -> 52 MB
  • Compressed: 48 MB -> 17 MB

These size reductions reduce:

• the download/extraction time (and bytes over the wire) of the Python archive during the buildpack build (this particularly helps when using CNBs locally, where users often won't have as fast connections as an EC2 instance)
• the archiving/compression/upload time of the build directory by the build system at the end of the build (whether that be for the slug for classic builds, or the layer exporting/pushing for CNBs)
• the app boot time at runtime (since smaller slug / layer to download on the runtime instance)

...plus they also reduce the chance of an app running into slug size limits when using heavier dependencies.

In the future I plan to explore switching the archives to using zstd instead of gzip, for further size/performance wins.