pr-coverage.yml repeated the test invocation and coverage plumbing that
ci-pr.yml and ci-nightly.yml already had. Move it into a composite action
alongside setup-go and setup-test, parameterised by what actually differs
between the three: -short, -p, where test results go, and whether
coverage is measured.

Nightly now measures coverage only on ubuntu-24.04. The other two
platforms were paying for instrumentation whose output was never
uploaded.

Also shorten the comments added along with these workflows.

Project coverage is the least trustworthy number in the comment: it
compares against whichever commit last had an upload, and moves with the
file set as readily as with the tests. Hide it and report patch coverage.

Add components for the subsystems reviews are drawn around, so a ledger
change is measured against ledger rather than against go-algorand.

Wait for every partition before commenting, so a comment is never written
from part of a run. Only pull requests are commented on, so push builds,
which upload two reports rather than six, are unaffected.

PR builds no longer measure coverage, so nothing reports the coverage of
a change before it merges. Add a workflow that does it on request:
commenting "/coverage" on a pull request runs the full -coverpkg suite
against its head and uploads the result to Codecov attached to that pull
request, where it can be compared against the baseline the push build
publishes for the merge base.

The run is measured the same way as the push build -- same tags, -race,
no -short, CIRCLECI set -- so the two are comparable. Only the
partitioning differs, 6 runners instead of 2, which changes how tests are
spread but not which of them run.

Codecov is given the head commit, branch and pull request number
explicitly. issue_comment workflows run with the default branch checked
out, so an upload left to infer its own context would be attributed to
master and would overwrite the baseline. A fork's branch is named
"owner:branch", matching Codecov's convention.

Only OWNER, MEMBER and COLLABORATOR comments trigger it, since it builds
and runs the pull request's code. The workflow itself always runs from
the default branch, so a pull request cannot change what it does, and the
job that checks the branch out holds only contents:read and no secrets;
the write permission needed to acknowledge and report lives in separate
jobs that never check out the branch.

Extract the -coverpkg package list to scripts/coverpkg.sh rather than
adding a fourth copy of it; the Makefile and both existing workflows now
use it too. Verified to produce the same 112 packages as the pipeline it
replaces.

Move the coverage uploads to codecov-action@v7, which replaces "file"
with "files", and drop scripts/travis/upload_coverage.sh, which nothing
has referenced since CircleCI went away.

ci-nightly.yml is the push-to-master job and already measures coverage
with -coverpkg across all go-algorand packages. ci-pr.yml measured it
without -coverpkg -- counting only the lines each package's own tests
exercise -- and uploaded that too. Both kinds of report end up attached to
commits in master's history, so the coverage Codecov reports for a master
commit depends on which workflow happened to upload for it. Adjacent
commits alternate between ~47.9% (639 files, 6 sessions, PR runs) and
~63.8% (481 files, 2 sessions, push runs):

    8cd5eb5f6  63.78%  481 files  2 sessions
    288e1997e  47.90%  639 files  6 sessions
    e8559cc9a  63.82%  481 files  2 sessions
    7b9cb4d53  47.86%  639 files  6 sessions
    3f8045596  63.83%  481 files  2 sessions

A PR's project-coverage delta was therefore decided mostly by which
regime its merge base happened to land in, roughly 16 points of noise
with nothing to do with the change under review.

Stop collecting and uploading coverage on PR runs unless the workflow was
dispatched with full_coverage, so every report Codecov holds is measured
the same way. Ordinary PR runs no longer pay for coverage instrumentation
at all.

Also drop flags.full_coverage.joined, which was meant to keep these
reports out of the project total but did not: on push commits the
full_coverage upload is the only session, so it became the total anyway.

When -coverpkg is set, "go test -coverprofile" writes each instrumented
block once per test binary that links the package, and does not combine
them. "go tool cover" sums the duplicates and reads such a profile
correctly, but consumers that take the first or last occurrence instead do
not: on a two-binary run of ./config ./protocol the same profile reads as
58.8% (summed), 49.60% (last-wins) or 11.04% (first-wins).

Codecov appears to be one of those consumers. Comparing the nightly
full-coverage report against the cheaper PR report on adjacent master
commits, 118 of 373 comparable files report *lower* coverage under
-coverpkg, which attribution alone cannot cause: the nightly run executes
a superset of the PR run's tests. Individual files collapse while their
siblings in the same package are untouched --
data/transactions/logic/sourcemap.go 100% -> 0%,
ledger/eval/txntracer.go 92.85% -> 0%, util/metrics/prometheus.go
78.12% -> 0%.

Collect raw coverage data instead ("go test -cover ... -args
-test.gocoverdir=DIR") and merge it with "go tool covdata", which emits
each block exactly once with counts summed across every test binary that
exercised it. Across the whole repository that is 49,425 blocks with no
duplicates, and costs about 1.3s (20MB raw -> 644KB merged -> 3.7MB
profile).

The merge runs as its own step guarded by !cancelled(), matching the
upload step, so a failed test run still uploads the partial coverage it
produced.

One reporting change is not a correction: -coverprofile synthesized 0%
entries for packages that no test binary links, and covdata does not.
That drops daemon/kmd, netdeploy/remote/nodecfg and
ledger/store/trackerdb/testsuite -- 3 files, 431 lines, all at 0% --
raising the reported figure by 0.40pp for denominator reasons alone.

Also reference tool.mod by an absolute path in GOTESTCOMMAND so that
"make cover PACKAGE=X", which cds into the package directory, can find
it; that target has been failing with "go: open tool.mod: no such file or
directory" since it was added.