Cloud Aggregation for Counter, Gauge and Rate

[mstoykov]

This should not require any changes in the cloud backend and possibly can be the beginning of general in k6 aggregation as those types of metrics can be easily aggregated in k6 and don't require the backend knowing that they were aggregated.

I propose that this is done separately for each type in the order Counter, Rate, Gauge as that seems to be the most beneficial order. And only for the cloud for now as this is where we already have some of the needed code, and then it can be refactored to be more general.

This has the potential to take a lot of CPU though because of the current way tags .... are :( . Because of this, this will definetely require a lot of benchmarks and tests that we get the same end results.

Relevant previous PRs #1538

[mstoykov]

Actually it seems Rate will be a problem :( as we are just sending a single value for it
https://github.com/loadimpact/k6/blob/d9bced340035e039407502773e664aebe9734815/stats/cloud/data.go#L90-L97
But in order to make this possible, we need to send how many trues and how many total we have (or some other variant of two values). This means that this will definetely need support on the cloud backend before it can be done.

This was also probably the one type that was probably even the best one to be done as all checks are actually rate, so this is a very common type of metric. I was previously under the impression that checks are Coutners ... which obviously isn't true ...

[mstoykov]

Closing this in favor of #2954