Preliminary bzlmod support

[aherrmann]

This configures the gazelle_cabal workspace to be compatible with bzlmod as a dependency module. Meaning another module can depend on it via bzlmod, however gazelle_cabal cannot itself be tested or built with bzlmod enabled, yet.

This also configures the example workspace to be compatible with bzlmod as a root module. Meaning the example can be built and tested with bzlmod enabled.

Enables bzlmod tests on CI, for now only for GHC version 9.4.5.

limitations / future work

• The root module cannot itself be tested or built with bzlmod, yet.
• The tests are not built with bzlmod, yet. The alternative-deps test requires renaming the stack snapshot workspace names to stackage-b and stackage-b-exe. This is currently not possible. One path would be a name attribute to stack_snapshot. However, this is not desirable as discussed in https://github.com/tweag/rules_haskell/pull/1962. Another approach is to use isolated extensions (requires Bazel 6.3) and remapping on use_repo. But, use_repo uses keyword argument syntax for the remapping target, and stackage-b or stackage-b-exe do (AFAIK) not form valid identifiers in Starlark.
• The GHC version is hard-coded in the MODULE.bazel file and fixed to 9.4.5. The version number is factored out into a variable. A simple future improvement would be to simply change that variable in place in the CI pipeline to test other versions.
• The Gazelle extension does not itself support bzlmod, yet. In particular, update-repos does assume a WORKSPACE setup.

closes #63 #66

[aherrmann]

This will require an update of the required CI checks on GitHub.

[aherrmann]

@Mergifyio rebase

[mergify[bot]]

rebase

🛑 Unable to rebase the branch because the pull request is queued

It's not possible to rebase this pull request because it is queued for merge