Provide shared implementation for "SHOULD/MAY" warn behaviours for backends

[pradyunsg]

It would be good to have a single shared implementation for detecting these cases, that various backends could share, while allowing each backend to choose how to handle each case.

x-ref #284 which made me think about the warnings that PEP 639 suggests that "build tools" SHOULD/MAY present.

---

Checklist, if we decide to do this:

• PEP 685, ~line 103

  If a project's metadata specifies an older core metadata version and the name would be invalid with newer core metadata versions, tools reading that metadata SHOULD warn the user.

• PEP 685, ~line 106

  Tools SHOULD warn users when an invalid extra name is read and SHOULD ignore the name to avoid ambiguity.

• PEP 685, ~line 108

  Tools MAY raise an error instead of a warning when reading an invalid name, if they so desire.

• PEP 794, ~line 175

  Tools MAY warn or raise an error when installing a project into a preexisting environment where there is import name overlap with a project that is already installed.

• PEP 639, ~line 268

  Note that the guidance on errors and warnings is for tools' default behavior; they MAY operate more strictly if users explicitly configure them to do so, such as by a CLI flag or a configuration option.

• PEP 639, ~line 324

  The error and warning guidance in this section applies to build and publishing tools; end-user-facing install tools MAY be less strict than mentioned here when encountering malformed metadata that does not conform to this specification.

• PEP 639, ~line 351

  Tools SHOULD report a warning and publishing tools MAY raise an error if one or more license identifiers have been marked as deprecated in the SPDX License List <spdxlist_>__.

• PEP 639, ~line 411

  Build tools MAY and publishing tools SHOULD produce an informative warning if a built distribution's metadata contains no License-File entries, and publishing tools MAY but build tools MUST NOT raise an error.

• PEP 639, ~line 436

  If only the License field is present, tools MAY issue a warning informing users it is deprecated and recommending License-Expression instead.

• PEP 639, ~line 463

  Otherwise, if this field contains a license classifier, tools MAY issue a warning informing users such classifiers are deprecated, and recommending License-Expression instead.

• PEP 639, ~line 495

  Build tools SHOULD validate and perform case normalization of the expression as described in the :ref:639-spec-field-license-expression section, outputting an error or warning as specified.

• PEP 639, ~line 619

  If the new license-files key is not present and the text subkey is present in a license table, tools SHOULD issue a warning informing users it is deprecated and recommending a license expression as a top-level string key instead.

• PEP 639, ~line 624

  Likewise, if the new license-files key is not present and the file subkey is present in the license table, tools SHOULD issue a warning informing users it is deprecated and recommending the license-files key instead.

• PEP 639, ~line 777

  For authors using the now-deprecated License field or license classifiers, packaging tools may warn them and inform them of the replacement, License-Expression.

[henryiii]

Don't we already warn in some/many/most of those cases?