PEP 639: Further update per discussion, w/flat license key, etc. (#2705)

Substantive content changes:

* Instead of adding a new top-level `license-expression` key for the license expression in the `[project]` table of the `pyproject.toml` source metadata, the PEP now specifies using the top-level string value of the `license` key for this purpose, which PEP 621 (PEP-621) reserved it for, and updates the `license-expression` and `license` key specs, and the examples, rejected ideas and other sections accordingly.
* Since this makes it not possible to convert a legacy `license` key to the new `License-Expression` field at build time, and that's not really advisable anyway, it drastically simplifies the normative Converting Legacy Metadata section to just a single normative statement, and updates/removes other mentions of it accordingly, and the (already rather unhelpful) example
* Likewise, it simplifies and refines the guidance in the Mapping classifiers to SPDX identifiers section to be more general and less focused on build time, and also allows tools to ignore redundant parent classifiers (Note: This section will be moved to an external appendix in the next PR, but I didn't move it here for ease of review)
* The `license_files` directory was renamed to `licenses` at the request of @brettcannon and to simplify things a touch
* The specified handling of the `license.file` key was a bit confused by a (apparently quite common) misunderstanding about how the specified file is used (to inject its text directly under the `License` field in core metadata, rather than included in distribution archives or its path specified in metadata) due to it being rather underspecified in PEP 621, which this revision corrects.
* Bump the core metadata version to reflect acceptance of PEP 685 as Metadata 2.3
* Bump the SPDX license list version to be up to date

Significant non-normative/editorial changes:

* Mention implementation of drafts of this PEP in Hatch and Setuptools, and also describes previous efforts in Setuptools and Wheel that this PEP builds on more clearly, as suggested on the discussion thread
* Reference the canonical project [source] metadata PyPA spec instead of PEP 621, use clearer language surrounding that, and update a few references to other PEPs
* Revise the Motivations and Rationale to be less duplicative/redundant, more balanced and focused more specifically on their respective areas (providing some background and describing the problem, and introducing and justifying the proposed solution, respectively)
* Add a short blurb making explicit the use of RFC 2119 terminology (MUST, SHOULD, etc)
* Update PEP headers
* Various other minor revisions to correct typos and other issues, clarify and simply the text, and improve source formatting.