v0.124.0

A Go project can name its own test-suite command in .rlsbl/config.json, and the target registry now owns which test options each target accepts.

Context

The built-in test step ran a hard-coded go test ./... -race -short -count=1
for every Go target, with no way to say otherwise. A module whose tests only
run through a front-end tool's generated entry point, or through the project's
own suite script carrying its timeout and parallelism caps, could not pass that
command and had no door to name a different one -- so the test-suite check
and the release preflight blocked on a suite that was never meant to run that
way. test.go.command is that door, read through the same per-target block the
pypi runner already reads, so both targets are configured in one shape.

Which targets accept a test.<name> block, and which options each one takes,
moved onto the target protocol rather than being listed in the config
validator. The registry is the single authority for per-target facts, and the
validator asking it is what keeps the recognized-target set, the per-target
option sets, and the validation itself from ever disagreeing.

Features

• Configurable Go test command. A Go project can now name its own suite command in .rlsbl/config.json under test.go.command (for example "scripts/full-suite.sh"). Both the test-suite check and the release's built-in test step run it from the project root in place of go test ./... -race -short -count=1, with the same timeout budget, the same timeout message, and the same failure reporting. Leaving the block out keeps the built-in command unchanged.