refactor: move tools/private/zipapp to tools/zipapp

[rickeylev]

The //tools/private package is reserved for developer tools used to
maintain rules_python. The zipapp tools support rule execution and
belong under //tools/ alongside tools like launcher.

Move tools/private/zipapp to tools/zipapp, update internal rule
attributes, adjust test imports and dependencies, update distribution
filegroups, and document the scope of //tools/private.

[aignas]

TBH I would love to keep each tool next to where it is used.

On the other handsome of the tools might be usable from multiple places, so the proposed structure LGTM.

[aignas]

Thought about it a little more and I am thinking that tools is basically something akin to src. Ideally (read "not need to have it all") I would love to have the following structure in the repo for better navigability:

• //python - the core rules python ruleset and the pypi/uv integrations. Since most of the stuff is exposed through bzlmod extensions, it does not matter much.
• //runfiles - For the runfiles library.
• @sphinxdocs - Sphinx helpers, maybe we can publish a wheel (but sphinx-bazel) already exists, so that we would not need to include it's pyproject.toml through uv workspaces.
• //pytest - pytest in pytest-bazel integration, which I think is probably a good idea to donate to this repo.
• @gazelle - already separate.

So //tools/zipapp falls under //zipapp under this way of thinking. The source in there could be under //zipapp/src/zipapp and it could have its own tests, etc. That said, it is here to support //python and it will never be split, so having it under //tools is fine.

Posting here so as to not forget about it myself. :)

[rickeylev]

I had a similar thought, but slightly different: create a top-level src/ directory for the py code that is closely coupled to the rule implementation.

gtg right now, but stepping back: i'm thinking we should think of the code layout in terms of chunks that get used together, or ease of code sharing, or distributable units. e.g. i'd love for prebuilt static binaries to be an option for the tools, and for it to be easy for us to control whether they're prebuilt or built-on-demand-from-source