feat: allow overriding rules in `whl_library` repository rule

[aignas]

WIP - this is to discuss an interface for allowing users to better customize the build process. Once this is defined, we can then implement something for allowing users to build from source in the build context. That would require the following missing pieces that should be implemented in other PRs:

• [ ] Using http_archive or implement a new sdist_library repository rule for handling sdist.
• [ ] A rudimentary py_sdist_library that allows invoking a PEP518 build backend in the build phase.

Related to the discussion in #2118.

[aignas]

I tried implementing it with bigger granularity, but then the question is what gets passed as whl and py_library deps because those could be something like

deps = ["//foo:pkg"] + select({
    "@os:linux": ["//bar:pkg"],
    "default": [],
})

And because of that reason we cannot just pass foo and bar as deps. Maybe we should see what happens if we do pass foo and bar and omit the implementation details of the selects to the rule, but that may be a step back in terms of abstractions.

[rickeylev]

I think I need to go look at the generated BUILD files to get a better sense of things...

Maybe step one should be refactoring so that the generated build file is simpler? See local_runtime_repo for what I mean: https://github.com/bazelbuild/rules_python/blob/main/python/private/local_runtime_repo.bzl#L32

The generated BUILD file is super simple and just calls a macro with the minimal args. You can just look at the define_local_runtime_toolchain_impl macro to see what ends up in that build file and don't have to dig out the generated build file.

---

I don't see why we can't pass a select()? The define_pypi_package function would be a macro. Under the hood it calls the rule and passes the deps object.

[aignas]

#2347 has replaced this when it comes to better abstractions. Whereas the overriding of the targets is a separate question.