feat: support bzlmod

[alexeagle]

fixes #12

[p0deje]

There are some failures on CI which I am not sure how to fix.

[p0deje]

This should load the version from ruby_version.bzl until multiple toolchains are implemented.

[alexeagle]

the MODULE.bazel file cannot load(). We can discuss alternative ways to make these line up.

[alexeagle]

The failure is because of the label here: https://github.com/p0deje/rules_ruby/blob/575267f22078de32b7aaecb74a178cc3753ab284/ruby/private/bundle.bzl#L13

The user declares a rules_ruby_dist when the toolchain resolves, but that repository is visible only to them, not to rules_ruby itself. We'll need a bit of refactoring to green it up, I'll look again when I have some fresh brain cells for it.

[alexeagle]

I've taken the simple answer, which is a small refactor to move that hardcoded label from rules_ruby and instead the user must provide it.

To make it non-breaking for existing WORKSPACE users I've used a macro implicit string->Label conversion to supply a default value.

I'm not sure this is a great answer, but I think the rb_bundle rule could use some redesign thinking anyhow, as it's doing too much in a repository context. So I think we could land this for now, so that we establish bzlmod compatibility, with the tradeoff that it will just slow us down a bit in the future as any refactorings will have to work for both bzlmod and WORKSPACE.

[p0deje]

LGTM - my only concern is over testing in CI at the moment since we always use MRI 3.2.1 and there is no way to change it for bzlmod.

[p0deje]

Shall we move this documentation for the rule to the macro?

[alexeagle]

My solution for this, at least with current stardoc, is to document both. Described at bazelbuild/stardoc#98 (comment)

[alexeagle]

concern is over testing in CI at the moment since we always use MRI 3.2.1 and there is no way to change it for bzlmod

Filed #23 for a long-term answer. For now I'll change this to just have a bzlmod job with its own matrix that doesn't have a dimension for ruby interpreter.