timeline: finish the aggregations refactoring

[bnjbvr]

#4576 introduced a manager for aggregations (edits, reactions, poll responses etc.), that will record them over time, and applying them when the aggregation is observed before the event it applies to (which could happen with SSS and backpaginations, notably).

The work there hasn't been finished, and it's promising in that it should allow for a few refactorings reducing the complexity of adding new items to the timeline:

• add unit tests for the aggregation manager
• take care of redactions in the aggregation manager (with test)
• take care of edits in the aggregation manager (with test).
  • This one might be fun, because of bundled edits, and we should only recall the latest edit, whatever that means — likely comparing the previous latest edit with a new edit's event position in the all_events array.
  • I think an event-focused/pinned-events timeline should always prioritize the bundled edit over other seen edits, as it's stateless. A live timeline should always prioritize the latest edit, and resort to the bundled edit otherwise.
• Finish refactor(timeline): replace TimelineEventKind #4655
• Make use of the above when handling a reply preview, instead of manually re-doing the work.
• With all of the above, we can selectively choose to only handle live aggregations, and not all live events in general. Resolve Replacements and redactions for pinned events aren't working in real-time #4643