Add metrics for scoreboard state: clocks and scores

[brian-brazil]

These allow tying performance metrics back to jam
times/numbers as people are more likely to know those
than NTP-synced unixtime that a monitoring system
like Prometheus usually deals with.

[riffreff]

It is not that simple. If the teams have a different number of skaters you end up with different row heights for the two teams.

[official-sounding]

@riffreff I think you meant your comment for #86, not here

[brian-brazil]

#84 I think you meant.

[official-sounding]

(you're right, #84 is the correct issue for the row re-sizing)

This change looks good to me. I'm assuming prometheus doesn't impose much of a resource penalty for it's metrics collection? is it worth considering putting the metrics collection behind a command line argument (or perhaps allowing turning off metrics collection with a command line flag?)

[brian-brazil]

If you don't hit the endpoint, this code will never be called. Even then it's quite cheap.

What does cost is the direct instrumentation elsewhere, but that's measured in nanoseconds. There's enough expensive endpoints already that I don't see a point in disabling just this one, particularly as it would make performance analysis quite a bit harder.