build branches, conflict, etc. on top of `change_set` and introduce `change_group` as user concept.

[samuelstroschein]

https://www.loom.com/share/610880c22ce5488aab98d0f1cbb0887a

Context

Change sets purpose is to "group" related changes, mainly for users to express an explicit "those changes belong together" intent.

However, other features like branches and conflicts build on change sets too. But, in order to not conflict with user intent, branches and conflicts introduce their own change sets.

• duplicate change set implementations

Proposal

If we build lix features on change sets and de-duplicate change sets, lix will become severely more performant and storage efficient.

• one change set implementation

• optimizing this one change set implementation = optimization for every feature

• [ ] introduce change group

• [ ] branches point to change set

• [ ] conflicts point to change set

• [ ] labels point to change group

[samuelstroschein]

we could also introduce change_set.immutable BOOLEAN to guard against user defined change sets that should not be mutated without the need to introduce change_groups