feat: add alias generation for pip parse

[corypaik]

Generate alias packages and targets for pip_parse under the parent repository. This serves two purposes. It allows for users to reference packages using a simpler @pypi//package_name without the import issues associated with putting the contents of the package there (as may be the case with pip_install following this naming pattern). Additionally, this allows users to override individual libraries either by default or based on select statements.

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [x] Feature (please, look at the "Scope of the project" section in the README.md file)
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A

Currently, in order to refer to a dependency by name with pip_parse one must use the syntax @pypi_package_name//:pkg. It it also not currently possible to override the dependencies of pip repositories using local packages or those built with Bazel. The only workaround available now is to define a repository (e.g., @pypi_package_name prior to calling pip_parse. This is not ideal, and does not allow for selecting a version to use (e.g., local vs. from pip) via flags.

What is the new behavior?

The alias packages add the option to refer to dependencies under one central repository using the syntax @pypi//package_name. Additionally, it allows users to override the library targets by default or using any valid select statement.

Note that the original names (e.g., @pypi_package_name//:pkg) remain unmodified, as do all functions in requirements.bzl. The only exception is to all_requirements, which now uses the aliases instead. Happy to adjust this behavior as desired, my primary usage is @pypi//package_name and a few interactive targets that use all_requirements.

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

Other information

I originally was working on a version which made the creation of alias packages optional (and disabled by default). After trying to profile both with and without the alias repositories I could not find any measurable difference so I got rid of the option entirely.

I've refactored the existing tests to work with these changes and added some notes to the pip_parse example, but I'd also be happy to add additional tests if need be.