tests: split a pytest session into shards

System tests are slow because every session builds its own site and runs
sequentially in one pod. Splitting the session lets it run in several pods
at once, trading CPU for wall clock.

Splitting happens per module, never inside one: tests in a module share
module scoped fixtures and the order in which they change the site. That
also sets the floor, no shard count can get below the slowest single module,
and the plan reports it so it is visible when more pods stop helping.

Every shard computes the whole assignment and keeps its own slice, so they
cannot disagree about who runs what, as long as they balance against the
same runtimes. Longest module first onto the emptiest shard, ties broken by
path, so the result does not depend on collection order. A module the
runtimes do not know, typically a test file the change under test adds, is
priced at its own test count times the mean runtime per test.

The runtimes come from one finished build, named as "<job>#<number>" with
the full job path. A finished test report never changes, so it does not
matter when a shard starts, and a reference job finishing halfway through
the run changes nothing.

There is no fallback. A shard that cannot get the runtimes fails instead of
balancing against something its siblings do not have, which would split the
suite twice and leave tests in neither, reported as nothing at all.

CMK-32643

Change-Id: I67f9bc45858642bfd7b77d61e4a3f8610e8de7a9