More control over thunks added to a branch

Nobody has claimed this yet.

Currently, it's not ergonomic to drop a thunk `add`ed.

This could be helpful in a number of cases:
- Dropping a thunk after encountering an error while attempting to commit
- Dynamically reordering a transaction? Reorganizing multiple transactions?? (This seems wild but possible)
- Rolling back a branch to a previous state before committing

This could be accomplished a couple different ways:

- Add operations like `dropNext()`, `skipNext()`, `flush(n)` (move queue pointer to `n`), `drop(n)`, which give fine-grained control over the mutable thunk queue within the branch, in the same vein as `flushNext()`
- Make branches immutable; each operation returns a _new branch_

Immutable branches are strictly more powerful, but have a couple of problems be measured:
1. copy-on-write on each operation. This is probably small in comparison to the other parts of the system.
2. how do we handle stale versions of a particular branch being committed?

```javascript
let bX = branch();
let counter = ref(0);

let bX0 = bX.add(() => {
alter(counter, n => n + 1);
});

let bX1 = bX0.add(() => {
alter(counter, n => n + 1);
});

let bX2 = bX1.commit();

bX0.commit(); // ERROR! Stale
```

Should we prevent `bX0` from being rebased, since a future version of it has already been comitted? Or should we treat each branch returned by `add` as completely separate?

Read the branch(), add(), and commit() entry points first to understand how queued thunks and branch versions are represented. Decide whether queue controls or immutable branches are the intended direction, including stale-branch behavior, then define the expected semantics for dropping, reordering, and rollback before adding coverage.

Written by the indexing model from the issue text.