partial undo/state overhaul

[apaleslimghost]

currently, if you undo creating 20 PRs, add a filter so there are now 15 repos, and redo the PRs, you get 20 closed PRs and 15 new PRs. ideal would be 5 closed and 15 reopened/force-pushed. this isn't possible with the current data architecture, where we don't keep track of undone steps and there's no link between say a repo object, its branch, and its PR.

i don't know how to do this. here are some thoughts:

• make each operation work on each item in the repos array. ie make repos sort of a first-class concept. this addresses linking between repos/branches/PRs and facilitates not creating PRs for branches with no changes but doesn't handle reopening PRs because there's no way to keep track of PRs when you undo that step
• make undo its own operation, and keep track of the shape of the data at each step. this is sort of horrible and it balloons the data format & makes it less readable but it means you've got snapshots of the data moving through time. might work better combined with the first idea.
• as i'm typing this i'm realising this is sort of like redux where "steps" are actions and "operations" are reducers
• the standard way of implementing undo/redo is maintaining two stacks of events, an undo stack and a redo stack, and moving events from the undo stack to the redo stack when undoing

• 48 would make undo/redo/replay self-healing

• why even store data in the state file if you're doing #48
• another use case this should support is inserting a filter earlier into the stack; what happens if it filters out repos with PRs should it close them?
• argh this is two-dimensional time it's keeping track of how a thing that's changing some things changes

halp

[apaleslimghost]

the approach i'm going to go with is: handlers for things like PRs will specify that they operate on a single item in an array (something like input = 'repos[].branch' ; output = 'repos[].pr'. then i'll add checking for an existing PR for that branch (see #65) and similar for each operation.

[apaleslimghost]

input	output	what goes on with handler
scalar	scalar	same as current
scalar	array	adds return value to each item in array
array	scalar	parallel, return values saved as array to output
array	array	parallel, each return value saved to item in output

[apaleslimghost]

with input/output types, the check needs to become "is this input type a subset of the union of all the previous types"

[apaleslimghost]

this approach is far too complex 🙃 instead, i'm going to decouple the input/output types from the actual state data, and make them abstract. this way, handlers get passed the entire state and can do whatever they want to it.