Discontinuous room timeline

[KitsuneRal]

This is necessary to enable cases such as: resolving an event permalink (a part of #252); fixing #232; dropping parts of timeline to save memory; and others. One way to implement it would be to deploy several timeline objects in the room and provide indexing across them (employed in other clients including Riot; harder for clients to use since there's no single data source). Another (possibly more robust but less flexible and likely more challenging) way is to allow the deque used now to be discontinuous (e.g. by means of inserting 'more events here' markers where gaps are expected and auto-downloading events when these markers are about to show on the screen).

[KitsuneRal]

One particular application of this feature would be actually the opposite: seaming together timelines across room upgrades. Having different timeline objects for that purpose is more flexible as it allows to support different validations/behaviours depending on the room version the timeline is taken from (have a single AbstractRoomTimeline class and do version-specific behaviour in derived classes). A deque with markers is rather poor at extending to this case (baking the polymorphic behaviour into the container logic looks like a complete design failure).