(WIP)

I am updating tile-pane and float-pane to use the new layout logic system. Once this is solid, I will be moving the functionality into the other existing commands.

I will detail here how I plan on accomplishing this (bugs are still being squashed). Note that function names can be changed; they were made hastily to get coding.

Given that we would like to be able to restore floating layout geometry, some new state needs to be added to struct layout_cell to track this. It was previously added to struct window_pane. I am not certain adding four new fields is the correct approach, but it is the simplest for now.

When a tiled pane is "floated":

1. Any previous geometry is fetched from the layout cell.
2. The geometry it occupies in the tiled layout needs to be reclaimed by either a sibling, or in the case that it is the last tiled pane in the parent, a sibling of the parent reclaims the geometry (example: splitw; splitw -h; floatp -t2; floatp -t1). This is currently being done in layout_cell_remove_tile.
3. The floating geometry needs to be determined using a combination of provided arguments, stored dimensions, and defaults in a priority of that order. I broke out some logic to reuse the argument parsing. This is happening in layout_cell_floating_args.
4. The expected layout and pane touch-ups happen.

When a floating pane is "tiled":

1. The floating dimensions are saved in the layout cell.
2. A neighbour is selected from layout_cell_get_neighbour (a neighbour is a sibling that exists in the tiled layout). Since floating panes now have meaningful layout positions, this will restore the pane to its previous position.
3. We perform a "split" (two functions have been broken out of layout_split_pane to reuse logic) in place and recursively resize siblings/parents as necessary to make room. This is happening in layout_cell_insert_tile. None of the old tiled dimensions are stored nor used for this calculation. There is no guarantee of consistent layout state between floating and tiling, so the simplest thing to do is a 50/50 split of the parents type. Logic can be added in the future to track IF the state hasn't changed, the old tiling dimensions can be used.
4. The expected layout and pane touch-ups happen.

A lot of the PR so far is pulling out existing logic into their own functions for reuse with two new workhorse functions layout_cell_remove_tile and layout_cell_insert_tile. I am anticipating using these in the logic to hide/show panes, which is why they aren't local to the tile/float commands.

Let me know if ya'll have any thoughts or questions on what I have here. The code is still being debugged, so is less useful to look at, but don't hesitate to provide feedback anyway. Thanks!

@nicm @mgrant0