refactor(pypi): translate wheel METADATA parsing to starlark

[aignas]

This PR starts using the newly introduced (#2692) PEP508 compliant
requirement marker parser in starlark and moves the dependency
generation from the Python language (whl_installer) to the Starlark
in the whl_library repository rule.

This PR is (almost) a pure refactor where no bugs are fixed, but this is
foundational work that also adds notes on how things will be moved
to macros (i.e. analysis phase) so that we can fix a few long standing
bugs and prepare for stabilizing the experimental_index_url (#260).

Refactor:

• I have migrated all of the unit tests from Python to starlark for deps
  generation from METADATA Requires-Dist fields.
• Read the METADATA file itself in Starlark.

Work towards #260, #2319, #2241
Fixes #2423

[aignas]

OK, for today that is it.

Current progress:

• Moved the METADATA file reading/parsing to starlark as well.
• (TODO) add tests for this newly added code.

Out of scope all of the below:

entry_points.txt reading/parsing in starlark and generating
py_console_script_binary targets is out of scope. I think it would be still
good to generate the entry point python files, but those should be generated by
the py_console_script_binary rule. The good thing is that we only need to
know the script names (i.e. the starlark parser can be minimal).

Then there is the namespace_pkg_dirs generation. We should just straight out
move this to py_library and have a flag implicit_namespace_pkg_dir. I think
the code move to starlark should not be too bad, because we can do the
following in the build context:

• Inspect the srcs list and deduct from the paths about which __init__.py
  files need to be added. This is only needed if we are not building venvs.
• ctx.actions.template would be suitable here, because the contents of the
  file is static.

Lastly, unzipping of the wheel in starlark with repository_ctx.
The reason for that is that the unzipping does a few things:

• Remap paths:
  • purelib: /site-packages
  • platlib: /site-packages
  • headers: /include
  • scripts: /bin
  • data: /data
• Replace the interpreter in posix scripts
• Set the installer metadata.

The idea that I have at the moment is to extract it to a sub-folder:
site-packages and then move the headers, scripts and data one folder up
if the rename_paths attribute does not work.

Once we move the pep508_deps calls to the analysis phase and these three
things are done, then we won't need any Python in the repository phase to
extract wheels and we could then create a whl_archive rule that could be
used to just specify the whl dependencies.

EDIT: Reworded what I said above. Actually I don't think it is good to add any code here, so PTAL.