Undo for GemStone code changes — manual/UX review first, please

[ericwinger]

Important

Please review this by USING it, not by reading it. Press F5, work through the script below,
and tell me whether the feature feels right — where the buttons belong, whether you can find them,
whether the messages say the right thing.

Not yet: file layout, code structure, naming, test coverage, bugs in the diff. There is a lot
of it (160 files) and none of it is worth your time until the shape of the feature is settled. I
will fix whatever comes out of this pass, and then ask for a proper code review.

Editing GemStone code has been one-way. This makes it reversible: one Undo covering everything
you have done since you connected, most recent first.

Try it (about ten minutes)

Press F5, connect to a stone, and open the GemStone Explorer.

1. Save a method. Change a method, save it. A notice appears with an Undo button — press it.
   The old source comes back, and the editor showing it reloads.
2. Dismiss the notice, then undo anyway. Save a method again, dismiss the toast, and look at the
   left end of the status bar: a purple ↩ Undo. Hover it — it names the exact change. Click it.
3. Delete a method, then undo. It comes back with its category, and the Explorer selects it.
4. Add a class variable and say yes to accessors. Undo once — the variable and both accessors go.
5. Add a class variable, then add a method that uses it, then undo the variable. It warns you
   first, naming the method that would be left reading nil.
6. Rename a method category, then undo. Same methods, renamed back, nothing recompiled.
7. Remove a dictionary, then undo. It comes back at the position it held, with its classes.
8. Move a class to another dictionary — right-click a class in the Classes or
   Hierarchy pane → Move to Dictionary… — then undo. It goes back where it came from.
   (Both this and Move to Category… were System-Browser-only before; they are on the Explorer's
   class menu now.)
9. Rename a class category onto one that already exists — the classes merge — then undo. Only
   the classes that actually moved go back; the ones already there stay put.
10. Change a class definition (add an instance variable), then undo. Note the button now says
    Revert, and it tells you what that costs before doing it.
11. Apply a refactoring (rename a method, say), then undo. This one opens a preview, because it
    can have rewritten methods all over the hierarchy.
12. Press Ctrl+K U a few times and walk backwards through what you did.

Nothing commits, in either direction.

What I would most like your opinion on

1. Where should the Undo button live? There are five ways to reach it right now, which may be
four too many:

the notice that follows an action	the one that actually gets used — it is where you are already looking
the status bar, far left	purple, stays put while connected, dims when there is nothing to undo, tooltip names the change
the Explorer Methods pane title bar	↩ icon
the editor title bar	↩ icon
the Command Palette	Undo Last Change…

Which of these earn their place? Is there somewhere better I have not thought of? The status-bar one
deliberately stays visible but dimmed when the stack is empty, on the theory that a control which
vanishes cannot be learned — you find it once by accident and then never again. Tell me if that is
wrong, or if it is just clutter.

2. Is Ctrl+K U the right shortcut? It follows the Ctrl+K prefix the other Jasper bindings use,
and it deliberately does not take Ctrl+Z — that stays with the editor, so undoing your typing
and undoing a GemStone change never get confused. The cost is that the obvious key does not do the
obvious thing when your cursor is in a GemStone pane rather than an editor. Would you rather Ctrl+Z
did GemStone undo when focus is in the Explorer, and accept the risk of getting the wrong one?

Where this is honestly not "undo"

Worth knowing before you report these as bugs — each is deliberate, and each says so in the UI:

• Changing a class definition is a REVERT, not a rollback. GemStone has no transaction savepoints
  and re-versions a class on every shape change, so what happens is that the earlier version is bound
  again. The class history grows; it never shrinks. Anything written on the newer version since is
  left behind on it, and a modal names those methods before it happens. The button says Revert
  rather than Undo wherever this is what you will get.
• Renames, and instance-variable add/remove, apply the opposite operation. Reversing a rename is a
  fresh rename in the other direction, not a rollback — which is actually safer here, since work you
  did after the rename is carried forward rather than discarded.
• A still-empty method category exists only in the pane. Creating one with + does not touch the
  stone until something is filed in it, so undoing that is a pane-only change. If you file a method
  into it first, the undo notices and acts on the stone instead.
• Some things refuse, and say why. A refactoring that migrated instances or deleted class-history
  versions records nothing — both commit and both are irreversible. Undoing the creation of a method
  category that has since been filled refuses rather than acting, because GemStone's removeCategory:
  deletes the methods in a category along with it.
• Undo is per session and per connection. A reconnect starts empty, and an abort clears it — an
  abort has already rewound the stone underneath every entry. The stack holds the last 25 things.

What is covered

Saving a method, adding one, deleting one, moving one to another category; creating a class, changing
its definition, removing it (with its subclasses, as one entry), saving its comment; adding a class
variable and its accessors; creating and renaming method categories; restoring a class version;
creating, renaming and removing a dictionary; moving a class between dictionaries; renaming a class
category and moving a class into another; and the refactorings — change signature, extract/inline
method, extract/inline temporary, move method, push up/down, rename method, rename temporary, plus
class renames, instance/class-variable renames, instance-variable add/remove, extract superclass,
insert superclass and split class.

Reading the commits, if you want to

Grouped by area rather than chronologically — 42 commits, and the first of each group is the one worth
reading:

• the stack itself — a generic per-session stack that knows nothing about refactorings; the
  refactoring engine is one kind of entry on it
• the reversers — one per kind: method slots, class bindings, class comment, class variable,
  method category, symbol-list dictionary
• the recording sites — the Explorer, the System Browser, the file-system provider, the file-in
  mirror
• the engine — GsRefactoringUndo and its 71 SUnit tests, filed in with the rest of the payload

Testing

Full suite green on both 3.6.2 and 3.7.5 with the engine installed: 7 214 passing across 463
files. The engine's own SUnit suites run in-stone on each version. The generic undo has its own
integration suite that is deliberately ungated — nothing in it needs the refactoring engine, which is
the claim that ordinary undo works on a bare stone.

Closes #434. Closes #452. Closes #174. Closes #297.

Every command in Jasper that changes code is now undoable. Two items on #452's list have no command
to record — delete a category's methods and revert a method (the latter looks like editor revert,
which is VS Code's own undo). If something has been missed, it is worth a fresh issue rather than
holding these open.