build(bridges): unify the C++ and java_uno test sets in one BUILD

main/bridges had diverged into two test approaches that could not coexist:
mainline carried the gtest-based cppuno_roundtrip_test alongside the x64
bridge targets (mscx_uno, mscx_uno_implib, cpp_uno_bridge), while the ww8 /
security line carried the java_uno JNI chain (test_any_idl -> test_any_jni)
plus its in-process JVM host.  Every rebase of those branches collided on
the load block and on the target list.

Takes the union rather than a side.  The two suites cover different things
and are both worth keeping:

  cppuno_roundtrip_test  cpp->uno->cpp round trip through the bridge's asm
                         trampoline; arch-agnostic (select()s msci/mscx).
  test_any_jni           java_uno JNI round trip hosted in an in-process JVM,
                         including the seq-size ceiling check (TestSeqSize).

Brings over the supporting rules mainline lacked -- //build/rules:java_run_test
(staged_java_test) and //build/rules:native_lib_dir -- plus the JNI launcher,
its embedded VC90-CRT manifest, and the transport .def/.rc.  javamaker_classes
and jar_from_directory were already in java_pipeline.bzl.

.bazelrc gains the two settings the JNI tests require: --enable_runfiles (the
runfiles tree is off by default on Windows, and the launcher resolves the
native-lib dir and classpath through %TEST_SRCDIR%) and --java_language_version=8
(rules_java's bundled JDK otherwise emits class 55, which the Java 8 JRE hosting
the bridge rejects with UnsupportedClassVersionError).

Squashed from d590d66b10 and 9f03a49f66 (Peter Kovacs, 2026-07-02); their
CLAUDE.md and security-internal/ edits are branch-specific and stay on their
branches.  Both test targets analyse clean.

Known follow-up: test_any_libs pins :msci_uno and test_any_jni pins 32-bit
Adoptium paths, so the JNI suite is x86-only for now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>