Non linear undo

[JordanMartinez]

This isn't ready to be merged, but gives you an idea on how I'm trying to implement this.

I still have a few things to figure out:

• How does Current Position get updated now that its position is relative to other changes being added/forgotten/undone/redone?
  • A NonLinearChangeQueue needs two lists: the first for tracking all of the changes it has added (for forgetHistory()) and the second for tracking which undos/redos it can currently undo/redo. Every time a queue undos/redos/adds (and forgets?) a change, all other queue's 2nd list needs to be updated.
• How should FixedSizeQueues be handled? The items to consider are the above situation and the creation of a new edit when a "bubbly" edit is split into two parts, the 'buried' edit that takes the place of the original, and the new 'bubbled' edit that gets put on the top of the graph?
• How should NonLinearChangeQueue#equals method be implemented? Currently, I'm using an int ID that can be set by the NonLinearUndoManagerFactory, but I am not sure if another approach would be better.
• How should the list of undoable/redoable changes be determined? This will use functional programming in some way
• What is the timeline of updates (e.g. adding, undoing/redoing, forgetting history, etc.)?
• Does the current approach insure that new updates are sorted accordingly? (where the first edit in either of the two lists in NonLinearChangeQueue was created before the next one)

[JordanMartinez]

I feel like my NonLinearChangeQueue's need to be more 'queue-like' instead of an object that distinguishes which queue with which a change is associated and that has a few methods from the UndoManagerImpl.

The principles I see are:

• DAG needs all undos and redos so it can efficiently update them all when a change is bubbled or somehow modified
• a ChangeQueue should store its valid/all undos/redos itself so that computations such as hasNext and next and hasPrev and prev are faster than my current approach of iterating through all the changes. My current approach will take longer the more queues and changes that are added at an exponential rate; thus, it needs to change.
• Since the DAG needs all undos/redos, a queue could store its allUndos and allRedos using an ObservableList in DAG and FilteredList (by source) in Queue approach, an approach I've used in the past. However, this approach's issue is the inability to further filter the list in the Queue by those changes which are valid. Since the validity of these changes needs to be updated every time, and not just the ones that are added/removed, this implies the usage of the non-existent ReactFX method ObservableList#flatMap
• Since that method doesn't exist, another approach is to calculate the valid changes in the DAG, and then push out those changes to their corresponding queue's list. Perhaps this could be done using a SuspendableList approach: suspend the list, clear it, iterate through the entire allUndos/allRedos and add the valid change to the corresponding list, then unsuspend all the queue's lists. That works for the UnlimitedChangeQueues, but what about the FixedSizeChangeQueues?
• At some point, the fixed size queues will need to only store so many changes before forgetting any new ones. This implies the usage of forgetHistory somewhere in there.

[JordanMartinez]

Closing since I believe my next PR's approach is the correct one to take.