feat: Add alias_kind directive support to Gazelle plugin.

[canislupaster]

Currently the collision detection prevents Gazelle from respecting alias_kind. This PR cleans up the behavior by referencing the configured alias and map kind instead of storing a bunch of mapped actualPy*Kind vars.

I've added two tests heavily based on respect_map_kind: one with just alias_kind, and one using both map_kind and alias_kind.

Fixes #3183 .

[gemini-code-assist]

Code Review

This pull request introduces support for the alias_kind directive in the Gazelle Python extension, allowing users to map canonical Python rule kinds to custom wrapper macros. The implementation centralizes rule matching logic through a new kindMatches helper and updates collision detection to respect both map_kind and alias_kind configurations. A potential breaking change was noted regarding the removal of the exported GetActualKindName function, which might affect external tools or other Gazelle extensions relying on the public API.

[dougthor42]

Thanks, TIL about alias_kind! I've been using map_kind this whole time...

Ah, no wonder: alias_kind was added in bazel-gazelle 0.41.0, and we only bumped to Gazelle >= 0.41 in #3404 / v1.8.0.

The WORKSPACE builds are failing because that still uses gazelle 0.36

@aignas I don't remember - are we blocked from upgrading WORKSPACE to gazelle >= 0.41?

[aignas]

I think we just forgot to bump gazelle in the Workspace. Can't remember about any blocking issues.

[dougthor42]

👍 I opened #3717 for the WORKSPACE change. @canislupaster please rebase once that's merged.