Replace service_test with extend_test_rule(parent)

[dzbarsky]

Summary

Replace service_test with extend_test_rule(parent), which extends an existing Starlark test rule with services and runs its inherited executable through svcinit. The extended rule preserves the parent rule's providers, runfiles, test environment, and test classification; its initializer adds services to data so Bazel also preserves service coverage. Because ctx.super() returns a raw DefaultInfo without an exposed executable or populated files_to_run, the implementation recovers parent executables from declared outputs or runfiles, including Windows JavaScript launchers.

Define inherited Go, shell, JavaScript, and native_test rules in tests/test_rules.bzl; replace two-target service_test declarations with single test targets; reuse @rules_itest//:exit0 for hygiene and startup/shutdown tests; restore separate test and task environment coverage; and update docs/itest.md. Parent test rules must expose data.

Validation

• bazel test //... in tests/: 44 tests passed.
• bazel test //... in the repository root: 2 tests passed.
• bazel coverage --enable_runfiles --instrument_test_targets --instrumentation_filter=//go_service,//so_reuseport,//test_env --combined_report=lcov //so_reuseport:so_reuseport_test //test_env:env_specified_in_task: both tests passed; go_service/main.go, so_reuseport/so_reuseport_test.go, and test_env/env_test.go appear in the combined LCOV report.
• buildifier -mode=check on every changed Starlark and BUILD file.

[Spikhalskiy]

This looks like the right long-term API and would let downstream users remove wrapper patches. Before merging, could these two cases be covered explicitly?

1. A parent test declares env_inherit and the extended rule preserves it without repeating the attribute.
2. An extended Python test loads an instrumented native library and produces native coverage. The current service coverage test proves service coverage, but not the test action native collector path.

Would you also consider keeping service_test for one deprecation release? Migrating a large set of existing wrappers atomically is fairly expensive.