Rate limit updates in the experimental UI and keep it fresh

Make the experimental UI honor the --show_progress_rate_limit flag.
While just dropping a status bar update if it happens too soon after
the last update shown would be easy, there are a few delecate points
to keep in mind.

Assume that several updates happen after another and then nothing for
a long time. Then the last(!) update is the one the user wants to see,
as it most accurately reflects which actions are running during the
long period. However, the simple dropping algorithms would show the
first of those state updates. So, whenever we refrain from updating due
to the rate limit we to make sure that an update will happen soon-ish,
even if no events are reported for a long time.

We do this by having (at most) one thread that periodically triggers
updates of the progress, if the rate limit allows this. This mechanism
is additionally used to ensure that the progress bar, when showing
time-dependent data is kept fresh. For this property we also add a test.

There is a third point to keep in mind: users (and also our tests) want
to see all phases. However, some phases (like loading) might be so short
that they happen in its entirety within a refresh interval. Therefore,
whenever a new important phase starts, we skip the rate limit interval
once; note that this happens at most a fixed number of times during the
entire build.

--
Change-Id: Iee68194d7eb92d6ef9efdc7abde6f56edfa21ce8
Reviewed-on: https://bazel-review.googlesource.com/#/c/3293
MOS_MIGRATED_REVID=119515272