Various rules were only ever invoked once and had minimal bodies.I don't see a benefit to the indirection.So this commit inlines rules to simplify the PGO logic.skip news

This commit overhauls the make-based build system's rules forbuilding optimized binaries. Along the way it fixes a myriad ofbugs and shortcomings with the prior approach.The old way of producing optimized binaries had various limitations:* `make [all]` would do work when PGO was enabled because the phony  `profile-opt` rule was non-empty. This prevented no-op PGO builds   from working at all. This meant workflows like `make; make install`   either incurred extra work or failed due to race conditions.* Same thing for BOLT, as its `bolt-opt` rule was also non-empty  and always ran during `make [all]`.* BOLT could not be run multiple times without a full rebuild because  `llvm-bolt` can't instrument binaries that have already received  BOLT optimizations.* It was difficult to run BOLT on its own because of how various make  targets and their dependencies were structured.* I found the old way that configure and make communicated the default  targets to be confusing and hard to understand.There are essentially 2 major changes going on in this commit:1. A rework of the high-level make targets for performing a build and   how they are defined.2. A rework of all the make logic related to profile-based optimization   (read: PGO and BOLT).Build Target Rework======================Before, we essentially had `build_all`, `profile-opt`, `bolt-opt` and`build_wasm` as our 3 targets for performing a build. `all` would aliasto one of these, as appropriate.And there was another definition for which _simple_ make target toevaluate for non-optimized builds. This was likely `build_all` or`all`.In the rework, we introduce 2 new high-level targets:* `build-plain` - Perform a build without optimizations.* `build-optimized` - Perform a build with optimizations.`build-plain` is aliased to `build_all` in all configurations exceptWASM, where it is `build_wasm`.`build-optimized` by default is aliased to a target that prints an errormessage when optimizations aren't enabled. If PGO or BOLT are enabled,it is aliased to their respective target.`build-optimized` is the logical successor to `profile-opt`.I felt it best to delete `profile-opt` completely, as the new `build-*`high-level targets feel more friendly to use. But if people lament itsloss, we can add a `profile-opt: build-optimized` to achieve almost thesame result.Profiled-Based Optimization Rework==================================Most of the make logic related to profile-based optimization (read: PGOand BOLT) has been touched in this change.A major issue with the old way of doing things was we used phony,always-executed make rules. This is a bad practice in make because itundermines no-op builds.Another issue is that the separation between the rules and what orderthey ran in wasn't always clear. Both PGO and BOLT consist of the same4 phase solution: instrument, run, analyze, and apply. However, thesesteps weren't clearly expressed in the make logic. This is especiallytrue for BOLT, which only had 1 make rule.Another issue with BOLT is that it was really easy to get things intoa bad state. e.g. if you applied BOLT to `pythonX.Y` you could notrun BOLT again unless you rebuilt `pythonX.Y` from source.In the new world, we have separate `profile-<tool>-<stage>-stamp`rules defining the 4 distinct `instrument`, `run`, `analyze`, and`apply` stages for both PGO and BOLT. Each of these stages is trackedby a _stamp_ semaphore file so progress can be captured. This shouldall be pretty straightforward.There is some minimal complexity here to handle BOLT's optionaldependency on PGO, as BOLT either depends on `build_all` or`profile-pgo-apply-stamp`.As part of the refactor to BOLT we also preserve the original inputbinary before BOLT is applied. This original file is restored ifBOLT runs again. This greatly simplifies repeated BOLT invocations,as make doesn't perform needless work. However, this is all besteffort, as it is possible for some make target evaluations to stillget things in a bad state.Other Remarks=============If this change perturbs any bugs, they are likely around cleaningbehavior. The cleaning rules are a bit complicated and not clearlydocumented. And I'm unsure which targets CPython developers ofteniterate on. It is highly possible that state cleanup of PGO and/orBOLT files isn't as robust as it needs to be.I explicitly deleted some calls to PGO cleanup because those callsprevented no-op `make [all]` from working. It is certainly possiblesomething somewhere (release automation?) relied on these files beingdeleted when they no longer are. We still have targets to purge profilefiles and it should be trivial to add these to appropriate make rules.

This allows easily customizing the arguments to `llvm-bolt` withouthaving to edit the Makefile.Arguments can be passed to configure and are reflected in configureoutput, which can be useful for log analysis.When defined in the Makefile we use `?=` syntax so the flags can beoverridden via `make VAR=VALUE` syntax or via environment variables.Super useful for iterating on different BOLT flags.

This ensures `LD_LIBRARY_PATH` is set. Without this, I was able totickle a libpythonX.Y.so not found error.

Before, we only supported running BOLT on the main `python` binary.If a shared library was in play, it wouldn't be optimized. That wasleaving a ton of optimization opportunities on the floor.This commit adds support for running BOLT on libpython.Functionality is disabled by default because BOLT asserts on LLVM 15,which is the latest LLVM. I've built LLVM tip and it is able toprocess libpython just fine. So it is known to work.

The generated sysconfig data during builds encodes a PEP-425platform tag. During native (target=host) builds, the bootstrappedcompiler runs Python code in sysconfig to derive an appropriate value.For cross compiles, we fall back to logic in configure (that codelives around the changed lines) to derive an appropriate platformtag, which is exported as an environment variable during builds.And there is a "backdoor" in `sysconfig.py` that causes`sysconfig.get_platform()` to return that value.The logic in configure for deriving an appropriate platform tagis a far cry from what's in `sysconfig.py`. Ideally that logicwould be fully (re)implemented in configure. But that's anon-trivial amount of work.Recognizing that configure makes inadequate platform tag decisionsduring cross-compiles, this commit switches `_PYTHON_HOST_PLATFORM`from a regular output variable to a "precious variable" (in autoconfspeak). This has the side-effect of allowing invokers to define thevariable, effectively allowing them to explicitly set the platformtag during builds to a correct value when configure otherwise wouldn'tset one.