Address duplication in the test suite

[Neil Vyas]

As discussed in #21 and #22, when we handle "nested" popups, we need to account for the parent window being either a Detour or any other sort of popup. As such, we need to have the test suite account for both these cases in every test case involving nested windows.

So, either

1. all test cases involving nested popups need to be tested with both nested Detour popups and nested windows generally; or
2. we must ensure that detour.Detour() behaves identically when nesting over either of the objects just mentioned.

(2) is clearly superior, though it's not clear how to achieve that actually, given that we don't have some sort of interface or abstraction layer for "the behavior of the parent window and its relationship with the detour popup" in the code right now (though, that could be done by inspecting the code). (1) could be accomplished by changing all the tests into "templates", where instead of writing the test cases directly, we have a function fn(popup_factory: fn () -> Popup) -> TestCase produce the cases, and we call that function once for each sort of parent popup we need to test, which for now are (1) Detour popups and (2) a generic popup.

[Roger Kim]

So, before responding to your points, I'd like to provide the context that I'm currently considering completely overhauling the testing framework for this plugin. The reason is because of this test. The test is currently disabled because it cannot work with the current testing approach.

The issue is that the current approach runs the test as a lua script via nvim -l .... This runs Neovim without a display and therefore does not trigger any WinResized events (as explained here). It will take some investigation to figure out what a better approach would be.

I still would like to fix any issues with the current approach so that anybody can clone this repository and run the tests out-of-the-box. I just wanted to let you know that, in the long run, the testing situation may need to be overhauled.