Large test suites are commonly split across CI machines, which Vitest, Jest,
and Playwright all support with a --shard flag. deno test had no
equivalent, so the whole suite had to run on one machine.

This adds deno test --shard=<index>/<count> (1-based index). The discovered
test files are sorted for a stable order, then split into <count>
consecutive, balanced groups, and only the files for <index> are run. Every
file lands in exactly one shard and group sizes differ by at most one. The
selection happens before any --shuffle, so a given shard runs the same files
on every machine regardless of the shuffle seed. Invalid values
(index > count, index or count of 0, missing /) are rejected at
flag-parse time.

Sharding is a pre-filter on the discovered file list, independent of how files
are executed, so it composes cleanly with filtering and any future test-runner
isolation/pooling changes.

Over-sharding is intentionally lenient: if count exceeds the number of
discovered files, the empty shards run zero tests and exit successfully rather
than erroring. This is the behavior that fixed-shard-count CI setups want
(Vitest instead errors and requires --passWithNoTests).

For now the shard is selected at run time, after the module graph for the full
suite has already been built and type-checked, so every machine still pays the
graph-build and type-check cost for the whole suite and only test execution is
parallelized. Moving the shard pre-filter ahead of type-checking, so each
machine only loads and checks its own subset, is a natural follow-up.

This intentionally does not include cross-shard result merging (a combined
summary across shards); each shard reports its own subset and fails its own CI
job, and a merge step pairs naturally with the json reporter as a follow-up.