Bound the time each package install of the catalog's provisioning takes

[estebanzimanyi]

Every apt-get call of the provision-meos action and of the OpenAPI
workflow runs through .github/actions/provision-meos/apt-get.sh, which
bounds the command's wall time with timeout, 600 seconds an attempt,
retries it, three attempts, and fails the step once every attempt is
spent, with apt's own status or 124 for a timeout. The download and dpkg
lock timeouts it passes bound one request each; the timeout bounds the
command, which a mirror serving at a crawl keeps alive through every
per-request limit. A composite action step takes no timeout-minutes, so
the bound sits in the one script each call runs.

Why. provision-meos is the step every consumer's CI runs before any of
its own: a stalled mirror holds the job until GitHub's six-hour limit
and every lane waits behind it.

Measured. Two fork runs, 36731927090 and 36736954866, spent 11 and 27
minutes in their first apt-get on a slow mirror, against about 4 minutes
upstream on the same commit. The helper, run against a stub apt-get,
returns at once on success, fails with status 100 after three attempts
of a failing command, and fails with 124 after three bounded attempts of
a hanging one.

Witness. This pull request's own CI runs every changed call: the pytest
workflow provisions with build-libmeos, which takes the six calls of the
action, and the OpenAPI workflow takes its two.