Migrate remaining native rules for Bazel 9 compatibility

Please incorporate the native-rule migration proposed in [PR #174](https://github.com/google/googlesql/pull/174) so GoogleSQL does not require the language rules removed from Bazel 9. This adapts [cloud-spanner-emulator#374](https://github.com/GoogleCloudPlatform/cloud-spanner-emulator/pull/374) to GoogleSQL's own BUILD files.

## Why this is needed

[Bazel 9 removes the remaining built-in C++ rules and disables automatic loading of external language rules by default](https://blog.bazel.build/2026/01/20/bazel-9.html). A downstream project upgrading its root build to Bazel 9 must load GoogleSQL's packages with that Bazel version, regardless of GoogleSQL's own `.bazelversion` pin. Implicit rule references can therefore prevent package loading before compilation starts.

GoogleSQL master `289c4bc6cf6e134129a032ccb2e4f849e000279c` still has implicit rules in `bazel/farmhash.BUILD`, `bazel/icu.BUILD`, the `native_utils` BUILD text, `googlesql/common/BUILD`, `googlesql/parser/BUILD`, the execute-query BUILD files, and `examples/bazel/BUILD.bazel`. `execute_query_test` also calls `native.sh_test`.

## Requested change

Load the C++, Java, proto, and shell rules explicitly, add the required direct module dependencies, and provide the temporary `--incompatible_autoload_externally` fallback for unchanged third-party BUILD files. Keep Bazel 7.6.1 as the project's pinned version and include the separate Bazel example. GoogleSQL uses Textmapper; the emulator's JavaCC/JDK changes are not applicable.

GoogleSQL's `.bazelrc` is not inherited by consuming root modules. Those roots may still need the same autoload flag for third-party archives until those archives migrate; this PR does not claim to remove every downstream Bazel 9 compatibility requirement.

## Validation and remaining limitation

Package-loading queries pass under Bazel 7.6.1 for the affected GoogleSQL packages, FarmHash/ICU/native_utils overlays, and the separate example module. A Bazel 9.0.0 consumer loads those packages with a test-only `single_version_override` selecting `rules_swift` 3.1.2.

Without that test-only override, Bazel 9 stops before package loading: `grpc` 1.81.1 requires `rules_swift` compatibility level 2, while `bazel_tools` requires compatibility level 3. That independent dependency conflict is not changed by this PR. These checks validate package loading, not compilation or runtime behavior.

I understand GoogleSQL does not accept external code contributions; the PR is a reference implementation for maintainers to incorporate through the internal development process.

Start by comparing PR #174 and cloud-spanner-emulator#374, then inspect bazel/farmhash.BUILD, bazel/icu.BUILD, the native_utils BUILD text, googlesql/common/BUILD, googlesql/parser/BUILD, the execute-query BUILD files, and examples/bazel/BUILD.bazel. Run the stated package-loading checks with Bazel 7.6.1 and the separate example module. Done means the affected packages load with explicit C++, Java, proto, and shell rules while retaining the pinned Bazel version and documented fallback.

Written by the indexing model from the issue text.