add ci config to test 7, 8 and 9 for bcr like setup

[aignas]

WIP

This is inspired by bazel-contrib/bazel-gazelle#2221. I don't have an ETA on this and will work as I have time, so feel free to add comments and what should be changed and how inf you wanna help out. :)

TODO:

• Add BCR-like configurations for gazelle and bzlmod examples
• Use matrix for full version coverage
• Bump dependencies
• changelog

Work towards #3392

[aignas]

OK, getting late, but I think this is a good start.

@rickeylev, do you remember what kind of limitations we have for CI slots?

[rickeylev]

There's a limit on the number of jobs. I'm not sure if its hard or soft.

Looking at the recent BCR failure, i'm guess it is covering windows+bazel 8 while we're not

[rickeylev]

Well, now I'm a bit confused.
BCR says its failing with 8.x, but this test should have been covering that (at least until the bazel 9 rc came out)?

Yet in this PR's refactored CI run, it's also giving the error BCR is giving.

The only difference seems to be the vendor step?

[rickeylev]

re: CI failures: I think we just need --windows_enable_symlinks, then it should be OK

[aignas]

I remember @meteorcloudy suggesting that we should avoid forcing users to set this flag, because it requires Windows admin permissions. If we need to add it, then the Windows support may not work properly. I think the interesting thing is that we need this flag because we are trying to use our binary in a sh_binary, so this requirement may be not related to rules_python requirements but to rules_shell requirements.

[rickeylev]

That's a good point and would explain what we see better. Yeah, the regular tests, which also show up as symlinks on disk (even without the enable symlinks flag), work fine

I tested all the 8.x.0 versions and they all have this same issue. Bazel 7 didn't.

[fmeum]

One of the failing runs tries to run bazel coverage on Windows with Bazel 7. That certainly isn't supported and if it worked before then only by chance. It may work in Bazel 9.