Metrics Collect improvement for delta temporality

[cijothomas]

During collect the hashmap is cleared out entirely, forcing updates() to re-insert entries to the hashmap after each collect. Since inserts require Write lock and heap allocation, we should avoid unnecessarily causing insertion.

One rough idea how to achieve this:

1. Associate a status with each tracker indicating if it has a collect pending or not. Update need to set this.
2. During collect, remove those trackers which has no collect pending.
3. For trackers that have collect pending, it must be collected and status updated to no collect pending.

This does introduce some extra cost, but it'll help avoid insertion frequency for those trackers that are constantly updated (at least once in collect period), as their trackers will not be removed from hashmap. This is a desirable feature for Metrics, where once a tracker is reported (i.e a timeseries), as long as user is not providing new timeseries, there should be zero memory allocations and write locks. In other words, after initial hydration, the steady state should not require any memory allocations, and won't cause an update thread to get blocked trying to acquire a lock.

[fraillt]

This has undesirable cost for cumulative temporality as well, because of the requirement to keep track of whether collect is pending or not.
However, it looks like temporality never changes for specific aggregation, which means that instead of having Sum aggregation with collection methods cumulative and delta, we could have Sum<generic over temporality> instead.
This approach would allow to have efficient update for cumulative, and efficient collect for delta.