Now we can incrementally use utility functions from pep425tags without
switching everything at once or converting in multiple places.

packaging.tags provides a simple `sys_tags` function for getting
applicable tags for the running interpreter, but it does not allow
customization of arguments.

packaging.tags provides three functions for getting custom tags:

1. `cpython_tags` - for CPython only
2. `generic_tags` - for any non-CPython Python implementation
3. `compatible_tags` - tags that are not specific to an interpreter
   implementation

Since pip allows users to provide explicit impl, platform, abi, and
version, we have to use these functions.

`cpython_tags` and `generic_tags` are mutually exclusive, and return tags
that are the highest priority. These capture the most specific tags.

`compatible_tags` are always applicable, and a lower priority since they
may just be compatible with e.g. the Python language version, but lack
any optimizations available in the interpreter-specific tags.

To be able to do a meaningful comparison between our current
implementation and the above functions, we need to segment the pip code
into pieces that look like them.

To that end, we now have copies of the current `get_supported` function,
one for each of the functions provided by packaging.tags, and will walk
through converting them to rely on packaging.tags. For each
simplification step, if desired, we can compare the implementation in
the packaging.tags function with what we're replacing in pip.

Specifically, for each function in turn, we will:

1. Refactor it locally, taking into account its new, more limited,
   responsibilities
2. Introduce the packaging.tags function for the case where there are no
   custom arguments provided
3. Customize arguments one-by-one and delegate to the packaging.tags
   function
4. When there is no pip-specific logic left, remove the intermediate
   function and use the packaging.tags function directly in
   `get_supported`

In the end all these functions will be gone again and we'll be left with
an implementation that relies solely on the tag generation in
packaging.tags.

Since these functions are copies of the existing code, there is no
behavior change except each tag will now be present 3 times. To
accommodate this we remove all but the first duplicate tag from the
set of all tags.

We put `_compatible_tags` last because it will provide the lowest
priority tags. The order of `_cpython_tags` and `_generic_tags`
here is not significant - when we start customizing them we will
introduce a condition so that they are mutually exclusive.

Since `_compatible_tags` is the function that will be responsible for
generating the non-interpreter-specific tags, we remove the
corresponding sections from `_cpython_tags` and `_generic_tags`. The
resulting tags in `get_supported` are equivalent because these were
the last tags to be computed in those functions, and `_compatible_tags`
is executed after them (so any non-duplicate tags it produces will be
last).

To reinforce the reponsibility of `_compatible_tags` we also remove the
abi-related tag generation, which is already handled in `_cpython_tags`
and `_generic_tags`.

We assume this function improves on our existing behavior, so use it
as-is. We will customize the arguments over the next few commits.

Since packaging.tags internally calculates platforms when not provided,
we skip the tests which patch functions assuming that manylinux
compatibility determination depends on them.

Since the behavior for both of these functions is the same, there is no
behavior change here. This will let us simplify `_cpython_tags` a bit.

We only call this function when the user or platform-provided
implementation is "cp", so we can inline the literal in place of the
parameter. This will make refactoring easier.

We assume this function improves the status quo over the current
`_cpython_tags`, so we use it when no arguments need to be customized.

Since `packaging.tags` has its own tests and derives defaults
differently than pep425tags, we also remove the applicable tests that
were testing against the result of a plain call to
`pep425tags.get_supported()`.

Since this function is only called for non-CPython interpreters, the
abi3-related branches are not relevant.

As with cpython_tags and compatible_tags, we assume this function covers
our use cases in the no-argument case and will customize our arguments
for it in a few steps.

Now that we're fully using packaging.tags, everything in the supported
list is already Tag.

Further, since each function is responsible for its own set of
non-overlapping tags, we can also remove the de-duplication.

Since we only call this function when platform is not None, we can drop
one of the branches. This is the only place using our manylinux
auto-deduction functions, so those can be removed next.

The remaining glibc-related functions are required to allow us to put
the libc version in the pip user agent (for stats).

Previously, these were used when the user did not provide an explicit
ABI. Now this is handled internally in `packaging.tags` (by
`_cpython_abi` and `_generic_abi`).

Now handled internally in `packaging.tags` (in `_platform_tags`).