Design a Speedrun Timer Synchronization Protocol (STSP?)

In order to visualize LiveSplit One as a Twitch extension we need to synchronize the runner's timer to the browser. Additionally we want to synchronize information between different LiveSplit Ones when racing with each other. So we need to design a synchronization algorithm. We want to design it in such a way, that splits i/o is using it too for their racing feature. And they want it to be timer agnostic, so it needs to support "dumb clients" that don't necessarily track everything properly or can even parse any split formats. However proper timers such as LiveSplit should synchronize pretty much everything without any loss of information. So the protocol needs to be flexible in this regard where each client can specify their capabilities.

Here's some rough ideas of how the protocol could look like (ignoring encoding for now):
```rust
struct ClientCapabilities {
can_parse_splits_of: Vec,
wants_splits_for_every_attempt: bool,
wants_rough_info_for_every_attempt: bool,
}

enum Event {
StartAttempt(Option),
DiscardAttempt,
ResetAttempt,
FinishAttempt,
UpdateSplit(usize, Time),
}

enum Splits {
Splits(Vec),
RoughInfo(SplitsInfo),
}

struct SplitsInfo {
game: String,
category: String,
attempts: usize, // This corresponds with the attempt count BEFORE the attempt started.
segments: Vec,
}

struct SegmentInfo {
name: String,
pb: Time,
}

struct Time {
real_time: Option,
game_time: Option,
}
```

We absolutely need to design this together with the splits i/o people and need to do this really soon as they are beginning to diverge too far.

The idea so far is that synchronizing a single attempt isn't too hard, we just need to update the times of individual splits until eventually the attempt is done. Then either the client is smart enough to update its information about the PB, possible history, etc. or we send an absolute snapshot of the current information again. Based on the client's ability of parsing the absolute snapshot, we either send some rough information or the full splits file. What may not be properly considered in this design are proxies, such as splits i/o that may not be "sufficiently smart clients", but need to serve the information back to clients that may be.

The initial design is mostly for observing timers, but you may also be interested in controlling the timer, so that's something that is probably going to be part of the protocol eventually too.

No implementation file or test is named. Start by reviewing the Rust event and capability sketches in this issue and coordinating with the splits.io people; done means an agreed protocol design covering timer synchronization, client capabilities, proxies, snapshots, and eventual control.

Written by the indexing model from the issue text.