(sub)split format

[cerpintext]

Currently subsplits depend on using a prefix in front of regular splits. This makes using them as an in-depth splits consisting of actual subsplits inherently variable based on rng or doing an action in one vs the next meaning fake golds, and almost completely negates the expected use of "subsplits", making them purely an aesthetic feature only.

One suggestion could be rewriting/extending the expected .lss format to also accept something like the following, where a segment can contain another group of segment-s ( can be used to solve #2027 ), while still keeping the same individual metadata like , , , etc. This would also serve to have a foundation to solve #1300, #1976 (dupe issue #2093 as well), #122, as more pros to it.

Immediate cons I can see would be requiring to rework the ui to support/reflect this as well, + added overhead when saving lss files and handling those with subsplits, but those could be handled by simply making it completely optional to expand with subsplits, just like it currently is.

<Segments>
--<Segment>
----<Segment></Segment> xN
--</Segment>
--<Segment>
----<Segment></Segment> xN
--</Segment>
</Segments>

[note: sorry if this belongs better in LiveSplit/livesplit-core or similar, it is not the simplest codebase to navigate]

[TheTaraStark]

This def feels like a core thing, since it would impact how .lss files are written/parsed, but I'm open to correction. Ty for doing all this research into other issues as well!

[just-ero]

@CryZe Can you transfer this to livesplit-core? The idea is to make subsplits something physical, instead of just a visualization. A Run could thus contain a list containing Segments and SegmentGroups, where a SegmentGroup contains a header, an icon and a list containing Segments (and more SegmentGroup, if the hierarchy should be able to go infinitely deep).