DM-40400: Create total AP pipeline timing metric

[kfindeisen]

This PR adds the timing metric introduced on lsst/ap_pipe#168 to the standard runtime metrics for ApVerify. Like all timing metrics, it is not run on ApVerifyWithFakes.

---

• Do unit tests pass (scons and/or stack-os-matrix)?
• Did you run ap_verify.py on at least one of the standard datasets?
  For changes to metrics, the print_metricvalues script from lsst.verify will be useful.
• Is the Sphinx documentation up-to-date?

[parejkoj]

One suggestion, otherwise this makes the use of the new metric quite clear.

[parejkoj]

Maybe worth a comment here that diaPipe is what sends the alerts, and thus is the endpoint of our runtime requirement? That might not be obvious to someone reading, especially if our pipeline grows some post-diaPipe afterburners.

We may also implement some things in diaPipe after packageAlerts (writing detectorVisitProcessingSummary comes to mind) so it's always going to be an upper-bound on the runtime.

[kfindeisen]

I don't think alerts are particularly relevant here. It's simply the last task in the "bare" AP pipeline (though quite a few metrics depend on diaPipe outputs).

[kfindeisen]

To clarify, this metric is pretty much irrelevant for "our runtime requirement", because the batch processing environment is completely different from the prompt one. Based on my experiments with the three ap_verify datasets, a good chunk of the time measured by this metric is time spent running other data IDs' tasks.