Fix ghost space left by SplitPane with top_level=true

[boazy]

Fixes #2579, #4984

When there is more than one pane in the tab, the tab.resize() is
called and the tab resize logic is reused to correctly resize all the
panes in the tab before adding the new pane split, so the new split
pane will not overwrite any existing pane.

The issue seems to be that after this resize, the tab "remembers" its
new size, and when the new split pane is closed, the tab is left with
ghost space which cannot be reused.

The fix is quite simple: we just need to immediately resize the tab
back to its original proportions. Since the underlying panes have
already been resized by tab.resize(), we don't need to keep the
restricted tab size.

I may have missed something, but this seems to work correctly.

[wez]

Thanks for diving in. I'm not sure about this though; if this results in the right outcome, should the above logic to resize be retained?
Can you provide more details on the precise problem scenario, and explain what you meant by the size being remembered?

[boazy]

I didn't write this logic, so I wasn't sure about why it exists in the first place. So of course I tried to remove it. But when I removed it completely, something else broke: The new pane text just wrote over the old pane's text without removing it. For instance, If I had a situation like this:

Before Split:

┌─────────────┬──────┐            
│> ls -1      │ P    │
│file.txt     │ a    │
│file2.txt    │ n    │
│file3.txt    │ e    │
│             │      │
│> echo Hi    │      │
│Hi           │      │
│             │      │
│> vim file.t │      │
└─────────────┴──────┘            

After Split (with direction=Down, top_level=true):

┌──────────────┬─────┐
│> ls -1       | P   │
│file.txt      | a   │
│file2.txt     | n   │
│file3.txt     | e   │
├──────────────┴─────┤
│mysh 1.0 Hi         │
│>                   │
│                    │
│> vim file.t        │
└────────────────────┘

It was a lot uglier in practice, but that's the basic gist. I'm not 100% what is the underlying issue, but I guess the existing panes' visible area doesn't get redrawn as necessary without calling resize if there is more than one pane.

So the resize() call does solve an actual issue. The main problem is that after the new pane you added is closed, the pane(s) that you resized won't refill the area of the closed pane, because the tab size is now smaller than full window size. This is exactly what issue #4984 refers to. Adding this extra resize() call resizes the tab to the full window size again, but the original (pre-split) panes' contents remain constrained to their new size.

[boazy]

An example of the issue that happens with the current code (without my changes) is provided in #4984 (reproduction of issue).

Due to this bug, top_level splits are practically useless. They are not needed to begin with if you just have 1 pane before the split, but if you have more than 1 pane they always leave unusable space behind. I don't think this fix can possibly make anything worse.