[Distutils] Restructuring metadata 2.0 to leverage the extension model

[Nick Coghlan]

It's (very) early days at this point, but I've taken the first steps
towards breaking up the metadata 2.0 monolith into multiple relatively
independent metadata extensions:

https://bitbucket.org/pypa/pypi-metadata-formats/commits/2a4692ee5d1181fdbb8008318c2a1aea7f14a0f8

Finalising metadata 2.0 is still in the "post CPython 3.4, leading up
to pip 1.6" time frame, but with 3.4 hitting feature freeze last
weekend with a mostly integrated pip, I figured it was time to share
at least something about my current plans for this, even if it's
another few months before I update it again.

The general aim is that the stuff that was previously identified as
the "essential dependency metadata" will be all that remains directly
defined in PEP 426, with everything else moved out to metadata
extensions.

A couple of other notable transitions started in this commit:

- install_hooks are out, metadata_hooks are in (as an extension). The
general idea is that you can register an interest in export groups and
other extensions, and installation tools will invoke your hooks at the
appropriate time. Still a lot of details to be worked out, but I
already like it much better than the previous install_hook model.

- started adding a formal notion of an "integrator suffix" to the
versioning PEP. This is a matter of recognising the fact that
redistributors will often apply additional patches to their
redistributed version, while still aiming to preserve the API and most
of the behaviour of the upstream release.

One key advantage of this model is that I'm proposing for the
extensions to be independently versioned, so we'd only have to update
the main metadata PEP in order to change the essential dependency
resolution metadata.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia