These issues were found after I started using a new development
environment.

ProfileAndDeviceIdFragmentTest had been updated to use a newer fragment
initialization pattern, but that's no longer needed and seems to be
causing what appears to be timing discrepancies between local dev and
CI.

The issue ultimately arose from test parameters being initialized after
they're needed in the launched UI. This type of change was tried earlier
in the branch, but reverted since it didn't seem necessary. It is,
however, necessary when there are environment differences (e.g. local
vs. CI) or when running certain tests individually.

Due to the difficulty in finding this issue, ActivityScenarioRule has
been added as a prohibited pattern in the static regex checks (along
with ActivityTestRule since that's deprecated and discouraged, anyway).

The test was suffering from some proto encoding inconsistencies that
seem to occur between some development machines vs. on CI. The fix
improves the test's robustness by extracting the raw encoded string,
verifying that the other outputs in the intent message correctly
correspond to that string, and that the string (as a parsed proto)
contains the correct values. As a result, the test no longer depends on
a hardcoded encoding value to be present for verification. This does
result in a bit more logic than is generally good to have in a test (and
it lengthened the test code quite a bit), but it seems necessary in this
particular case.

This is a script-specific dispatcher which will allow for better
asynchronous support in upcoming PRs (especially for command execution).
This change serves to prepare for those changes.

The main change here is ensuring that Bazel 4.0.0 is used & bzlmod
disabled in newer versions of Bazel when running operations in a test
Bazel environment.

This commit also introduces some more timing tweaks on CommandExecutor
for some tests, though these only affect very specific tests (as many
script tests directly call a script's main() function and thus don't
overwrite its executor behavior).

This commit attempted to introduce "--batch" mode to runs, but the
isolation didn't actually seem to improve stability and, instead,
substantially slowed down some of the tests.

…ipt-execution-support

Conflicts:
	scripts/src/java/org/oppia/android/scripts/ci/ComputeAffectedTests.kt
	scripts/src/javatests/org/oppia/android/scripts/ci/ComputeAffectedTestsTest.kt
	scripts/src/javatests/org/oppia/android/scripts/common/BazelClientTest.kt

Plus, actually makes use of the new script background dispatcher in
CommandExecutorImpl to make the new wiring make more sense (though its
real utility will come in a follow-up PR).

…ipt-execution-support

This was done by removing the //testing dependency and, instead, having
instrumentation targets depend on the direct module within //testing
that they need to build. This module & its corresponding implementation
binding (and tests) needed to be moved out of //testing and into their
own /firebase package.

…ecific-issues

Also includes some minor clean-ups within TestBazelWorkspaceTest.

…ecific-issues

…ipt-execution-support

…ipt-execution-support

…ecific-issues

…ecific-issues

…ipt-execution-support

Required upgrade of kotlinx-coroutines-core.

…ntTest.kt

Co-authored-by: Adhiambo Peres <59600948+adhiamboperes@users.noreply.github.com>

…ipt-execution-support

Conflicts:
	third_party/maven_install.json

…ipt-execution-support