[Monitoring] Adding a build age metric

[vitorguidi]

Motivation

We currently lack awareness on how old builds are during fuzz task. This PR implements that, by making the assumption that the Last Update Time metadata field in GCS is a good proxy for build age. Documentation reference

Approach

Symbolized and custom builds do not matter, thus all builds of interest will be fetched from build_manager.setup_regular_build. Logic for collecting all bucket paths and the latest revision was refactored, so that setup_regular_build can also figure out the latest revision for a given build and conditionally emit the proposed metric.

Testing strategy

!Todo: test this for fuzz, analyze, progression

Locally ran tasks, with instructions from #4343 and #4345 , and verified the _emmit_build_age_metric function gets invoked and produces sane output.

Commands used:

fuzz libFuzzer libfuzzer_asan_log4j2

progression 4992158360403968 libfuzzer_asan_qt

analyze 4992158360403968 libfuzzer_asan_qt (disclaimer: build revision was overriden mid flight to force a trunk build, since this testcase was already tied to a crash revision)

Part of #4271

[jonathanmetzman]

Does this need a review?

[vitorguidi]

Does this need a review?

I am triggering the reviews once the code gets to a good enough state, I will add a WIP tag to the next ones to signal that.

[alhijazi]

LGTM % comment