feat(cascadingfilter): refactor the code, better support of decision history

[pmm-sumo]

This change introduces several new things

1. Decision history is now stored in LRU cache. This allows for better managing of long-running spans. Also, the decision history is no longer tied to batches and those can be released earlier. The param is controlled by history_size (by default equal to num_traces)

2. Released traces now have info about which rule sampled them, if possible, e.g.

     -> sampling.rule: STRING(filtered)
     -> sampling.filter: STRING(foo)

3. The volume of traces that arrived late (after decision_wait) can be now controlled via prior_spans_rate param (by default 50% of spans_per_second). The limit is not counted towards spans_per_second. Those are also marked as such (though no probability is calculated for them). E.g.

     -> sampling.rule: STRING(filtered)
     -> sampling.late_arrival: BOOL(true)
     -> sampling.filter: STRING(probabilistic)

4. Additional metrics provide information on number of spans filtered, e.g.

otelcol_count_decided_spans{cascading_filter_decision="Sampled",processor="cascading_filter",service_instance_id="f5ab1029-a135-42fc-a70e-7a1931615d8c",service_version="v0.54.0-sumo-0-4-gdde2fd6a89"} 7
otelcol_count_late_spans{cascading_filter_decision="Sampled",processor="cascading_filter",service_instance_id="f5ab1029-a135-42fc-a70e-7a1931615d8c",service_version="v0.54.0-sumo-0-4-gdde2fd6a89"} 2

[andrzej-stencel]

I'm not sure I like the names of these metrics:

• why isn't count a suffix of the metric name?
• do we even need the count in the name? Wouldn't otelcol_late_spans be enough?
• Shouldn't metric names be scoped to the component that emits them? So this metric should actually be named otelcol_processor_cacadingfilter_count_late_spans or similar?