[chore] [deltatocumulative]: linear histograms

[sh0rez]

Description

Finishes work started in #35048

That PR only partially introduced a less complex processor architecture by only using it for Sums.
Back then I was not sure of the best way to do it for multiple datatypes, as generics seemed to introduce a lot of complexity regardless of usage.

I since then did of a lot of perf analysis and due to the way Go works (see gcshapes), we do not really gain anything at runtime from using generics, given method calls are still dynamic.

This implementation uses regular Go interfaces and a good old type switch in the hot path (ConsumeMetrics), which lowers mental complexity quite a lot imo.

The value of the new architecture is backed up by the following benchmark:

goos: linux
goarch: arm64
pkg: github.com/open-telemetry/opentelemetry-collector-contrib/processor/deltatocumulativeprocessor
                 │ sums.nested │             sums.linear             │
                 │   sec/op    │   sec/op     vs base                │
Processor/sums-8   56.35µ ± 1%   39.99µ ± 1%  -29.04% (p=0.000 n=10)

                 │  sums.nested  │             sums.linear              │
                 │     B/op      │     B/op      vs base                │
Processor/sums-8   11.520Ki ± 0%   3.683Ki ± 0%  -68.03% (p=0.000 n=10)

                 │ sums.nested │            sums.linear             │
                 │  allocs/op  │ allocs/op   vs base                │
Processor/sums-8    365.0 ± 0%   260.0 ± 0%  -28.77% (p=0.000 n=10)

Testing

This is a refactor, existing tests pass unaltered.

Documentation

not needed

[sh0rez]

This refactor effectively eliminates the need for the data package, as we no longer rely on type characteristics.

I'll refactor datapoint addition in a future PR, making this part more clear, maybe like this:

var add data.Aggregator = new(data.Add)

switch into := any(dp).(type) {
case pmetric.NumberDataPoint:
	add.Numbers(into, dp)
case pmetric.HistogramDataPoint:
	add.Histograms(into, dp)
}

[ArthurSens]

I did a first pass only through the benchmark. I totally understand my comments are nitpicks, I'm just sharing my personal preference when it comes to code style.

From our conversations I understand you prefer a more "declarative" style, but to me it makes the code way harder to read since I expect thing to run in the order they are written. Scrolling up and down several times until I finally understand what it does makes code less readable in my opinion.

Again, not a blocker!

[sh0rez]

@ArthurSens while the benchmark is split by datatype, I only ran for sums as the processor part (stream tracking, etc) is the same across all datatypes. speed differences only come by add implementation