Update test scripts for Bzlmod compatibility

[mbland]

Description

These are mostly small changes to make test assertions more flexible between WORKSPACE and Bzlmod runs.

For Bzlmod runs:

• Fixed test_scala_config_content from test_scala_config.sh by changing a path from external/io_bazel_rules_scala_config to external/*io_bazel_rules_scala_config.

• Fixed a number of tests by updating expected output messages to allow them to start with either @// or @@//.

• Fixed test_stamped_target_label_loading from test/shell/test_strict_dependency.sh by accommodating the canonical io_bazel_rules_scala_guava repo name. Also allows for the optional current Scala version suffix.

Also made these other important changes:

• Updated all the assertions in test_helper.sh to use Bash builtin regex matching via _expect_failure_with_messages instead of grep. This allows the expected message patterns to use full regular expressions while avoiding forking a new process. This new function helped reduce duplication in that file at the same time.

• Added --repo_env="SCALA_VERSION=..." to each test script called from ./test_coverage.sh, and set SCALA_VERSION to 2.12.19 in each of these files. Using other Scala versions technically works, but the output is slightly different, causing the diff commands in the test cases to fail.

• Updated test_version.sh to copy the top level .bazelversion file into its test repo.

• Changed how test_version.sh handles injecting twitter_scrooge repos into the WORKSPACE file. This will make it easy to do the equivalent for MODULE.bazel when the time comes.

Also includes a few minor, opportunistic formatting cleanups.

Motivation

Part of adding Bzlmod support per #1482.

I'm breaking this out to make sure the current default build configuration continues to pass as I carve off more of my fork's Bzlmod working branch. At the same time, the later changes can land without including so many test changes.

cc: @BillyAutrey @jayconrod @benjaminp @TheGrizzlyDev

[mbland]

On another note, I'm going to open a new PR to try to bump rules_java to 7.11.1 to see if it resolves this persistent "Bazel green head" CI breakage:

bazel --nosystem_rc --nohome_rc info
ERROR: Failed to load Starlark extension '@@rules_java//toolchains:toolchain_utils.bzl'.
Cycle in the workspace file detected. This indicates that a repository is used prior to being defined.
The following chain of repository dependencies lead to the missing definition.
 - @@rules_java
This could either mean you have to add the '@@rules_java' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive dependencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.
ERROR: cannot load build configuration key because of this cycle
Traceback (most recent call last):
  File "bazelci.py", line 4588, in <module>
    sys.exit(main())
  File "bazelci.py", line 4556, in main
    execute_commands(
  File "bazelci.py", line 1321, in execute_commands
    bazel_version = print_bazel_version_info(bazel_binary, platform)
  File "bazelci.py", line 1623, in print_bazel_version_info
    execute_command(
  File "bazelci.py", line 2750, in execute_command
    return subprocess.run(
  File "/usr/lib/python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['bazel', '--nosystem_rc', '--nohome_rc', 'info']' returned non-zero exit status 2.

[mbland]

Ah, just reminded myself of the problem with rules_java and WORKSPACE. Filed https://github.com/bazelbuild/rules_scala/issues/1625 for a general discussion, so it doesn't get buried here.

[mbland]

Rebased and passing after #1627, including latest Bazel 7.3.2.