on my keyboard, those are much more convenient to press than the regular
plus and minus keys. the regular plus key is shift+equals, so increasing
the font size requires a ctrl+shift combination while decreasing it only
requires ctrl, which is awkward.

I eventually want to split terminals by replacing one terminal by two
terminals inside a Paned. As a first step towards that, can I put every
terminal inside a Paned (with a dummy button on the other side of the
pane) without breaking the rest of the code?

I want to add a TabPaned, and it seems weird for the ScrolledWindow to
be identified more vaguely than the other widgets surrounding the
terminal.

compareScrolledWinAndTab was used to find the FLTab entry corresponding
to a given Widget in a Notebook. Now that Notebook entries are Paned
widgets containing a ScrolledWindow containing a terminal, and not
simply a ScrolledWindow containing a terminal, we need to search for the
Paned, not for the ScrolledWindow.

We can't show a Paned any more that we can show a ScrolledWindow, but at
least we can include a dummy entry for it in the Show instance, to match
the record's real shape.

We were previously trying to detach the ScrolledWindow, but since the
Notebook now contains Paned widgets, it was not found and the tab was
not detached.

so that it also describes the new Paned field.

Like the last few commits, the relabelling code was looking for a
ScrolledWindow but should now be looking for a Paned.

I previously edited the invariant checks so they would drill down the
Paned in order to find the ScrolledWindow and compare it with the
TMNotebookTab's ScrolledWindow. But directly comparing the Paned with
the TMNotebookTab's Paned is much simpler.

Since each of the two terminals have a ScrolledWindow associated with
them, this required moving the ScrolledWindow field from the
TMNotebookTab to the TMTerm.

More importantly, this refactoring revealed many places where the two
terminals were treated differently, and that code was changed to treat
both terminals the same. This was made easier by the addition of a lens
pointing to the focused terminal (which is currently always the left
terminal), and a traversal pointing at both terminals.

Also, update the tmNotebookTabFocusIsOnLeft field to reflect the
currently-focused pane.

The (followUp <- do ...) pattern is needed in order to avoid a deadlock
when the onWidgetFocusInEvent callback tries to grab the MVar which is
already locked.