Split rules_nixpkgs into separate components

[aherrmann]

Requirement of #181

Is your feature request related to a problem? Please describe.

The new bzlmod dependency management requires rule sets to declare all their direct dependencies upfront.
rules_nixpkgs is in the situation that it depends on many other rule sets. In principle, it could depend on every Bazel extension that provides a compiler toolchain like rules_cc, rules_go, rules_python, etc.

Before bzlmod this was not a problem, because dependencies were lazy - in the sense that e.g. nixpkgs_go_configure depends on rules_go, but a user only needs to worry about that dependency when they actually load @io_tweag_rules_nixpkgs//nixpkgs:toolchains/go.bzl.

With bzlmod all these dependencies need to be declared upfront in the MODULE.bazel file with version constraints. Meaning, rules_nixpkgs, as is, would introduce a large set of transitive dependencies for any of its users.

This is problematic as it could unnecessarily inflate the set of transitive dependencies of a project using rules_nixpkgs and expose users to version conflicts in transitive dependencies that they don't even want to use. It's also problematic as it would block modularization of rules_nixpkgs until all of its dependencies have been successfully modularized.

Describe the solution you'd like

The issue can be avoided by splitting rules_nixpkgs into separate Bazel modules, one for every language integration.

This could take the following form:

• rules_nixpkgs_core:
  Defines nixpkgs_git_repository, nixpkgs_local_repository, and nixpkgs_package;
  and exposes other common functionality.
• rules_nixpkgs_cc:
  Defines nixpkgs_cc_configure, etc.
• rules_nixpkgs_java:
  Defines nixpkgs_java_configure.
• etc.
• We can keep a top-level rules_nixpkgs that re-exposes all these components for compatibility with the legacy non-bzlmod workflow.

Note, the intent is not to create separate Git repositories for all these components - this should not be necessary. It should still be possible to maintain all these components within the same Git repository.