Investigate if the Aggregator API should handle attributes

[MrAlias]

It looks like there's a lot of logic baked into the Sum aggregator that could be treated at at higher level in the SDK, to me. I'm referring mostly to the appearance of a map[attribute.Set]N inside this type, whereas a map could be managed independently of the specific aggregation in use. When it comes to managing synchronization of removing stale entries from these maps, the logic ought to be identical across aggregators, I figure. For this reason, I was expecting to see a type that represents either an integer sum or a floating point sum, but not a type that represents a map of values, in this PR.

Originally posted by @jmacd in #3000 (comment)

• Determine if there are enough similarities to abstract the mapping of aggregations to attributes across all aggregators to abstract into a higher level of the SDK.
• Implement finding with the optimal solution.

[MadVikingGod]

Related to #3006

[MrAlias]

We no longer plan to do this.