Create ThreadView to track threads in a room

[nvrWhere]

This is some initial work to make supporting threads easier. As part of the thread spec the root event gets some aggregation in the unsigned of the root event. However this is not automatically sync when the thread is started or a new message is added so we can't just rely on it's presence.

This leaves us with 2 options:

1. Update the root event from the server every time a thread is started or updated - this will have a delay and hit the server
2. Track this info ourselves

This PR does number 2.

A new ThreadView is created which holds a list of Thread objects each representing the info for a single thread. As new events are added to the timeline each one is now checked to see if it is threaded and if so a Thread is either updated with the info as required or created if it is a previously unknown thread.

This is intentionally a very simple start, I intend at some point for it to contain it's own timeline but before we can do that we would have to decide how we want to manage having the same event in multiple timelines.

[KitsuneRal]

I happen to have the answer to the question about having the same event in several timelines. We really should separate the concerns of storing events and referencing them. Each room should have its own storage of events (could be unique pointers because we rarely delete events atm, but we could also use shared pointers or Qt's shared data paradigm); any event container (state or timeline) would then simply refer to the event. Event ids are obvious keys for the hash map storage, to find them whenever they are mentioned in sync/history batches. That really is it. It cannot be implemented without breaking the API because Room::Timeline is exposed in the API; but that's certainly something achievable for 0.10 and shouldn't disrupt client code too much.

[nvrWhere]

I happen to have the answer to the question about having the same event in several timelines. We really should separate the concerns of storing events and referencing them. Each room should have its own storage of events (could be unique pointers because we rarely delete events atm, but we could also use shared pointers or Qt's shared data paradigm); any event container (state or timeline) would then simply refer to the event. Event ids are obvious keys for the hash map storage, to find them whenever they are mentioned in sync/history batches. That really is it. It cannot be implemented without breaking the API because Room::Timeline is exposed in the API; but that's certainly something achievable for 0.10 and shouldn't disrupt client code too much.

As it so happens this is exactly what I was thinking.

[sonarcloud]

Quality Gate passed

Issues
7 New issues
0 Accepted issues

Measures
0 Security Hotspots
10.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[KitsuneRal]

A few comments on the current code.

[KitsuneRal]

Why std::unique_ptr and not Thread itself? I don't see polymorphism being involved, and I'm not sure what other reasons might require dynamic allocation of a structure the size of 4 pointers.

[nvrWhere]

So currently the Thread object is not copy assignable by design so this makes erasing possible. Maybe however this is just a sign that std::vector is not the right container