Fix E1312 when quitting a window

I've added a couple more changes to this PR to address a couple other areas of concern. It should now handle vim-9 with the newer handling, but pre-vim-9 will still behave as the old method.

I've tested the following scenaios

autoclose_netrw=0 test cases

autoclose_netrw=0, single file, single window

In this scenario, open a single file in a single window. Then with Tagbar open and NERDTree open, hit the :q from the main window.

[x] vim-8.1: NERDTree window only remaining window
[x] vim-9.1: NERDTree window only remaining window

autoclose_netrw=0, single file, multi-window

Open a single file, split the window, then open Tagbar and NERDTree. Then hit :q from the one of the split windows

[x] vim-8.1: the split closed leaving all other windows open
[x] vim-9.1: the split closed leaving all other windows open (this was previously failing with my last attempt)

autoclose_netrw=0, multi-file, single-window

Open multiple files in different buffers, but only a single window. Then open Tagbar and NERDTree. Then hit :q from the main window.

[ ] vim8.1: File window closes, and Tagbar window closes leaving the netrw (NERDTree) window open but both files as active buffers. This is a behavioral bug with current tagbar code it looks like
[ ] vim9.1: File window closes, and Tagbar window closes leaving the netrw (NERDTree) window open but both files as active buffers. Still a bug, but same behavior as vim8.1 at least

autoclose_netrw=0, multi-file, single-window, one file edited but not written

Open multiple files in different buffers, but only a single window. Then open Tagbar and NERDTree. Next edit one of the files, but don't write it. Then hit :q from the main window.

[ ] vim8.1: File window closes, and Tagbar window closes leaving the netrw (NERDTree) window open but both files as active buffers. This is a behavioral bug with current tagbar code it looks like
[ ] vim9.1: File window closes, and Tagbar window closes leaving the netrw (NERDTree) window open but both files as active buffers. Still a bug, but same behavior as vim8.1 at least

autoclose_netrw=1 test cases

autoclose_netrw=1, single file, single window

In this scenario, open a single file in a single window. Then with Tagbar open and NERDTree open, hit the :q from the main window.

[x] vim-8.1: all windows close and vim quits
[x] vim-9.1: all windows close and vim quits

autoclose_netrw=1, single file, multi-window

Open a single file, split the window, then open Tagbar and NERDTree. Then hit :q from the one of the split windows

[x] vim-8.1: the split closed leaving all other windows open
[x] vim-9.1: the split closed leaving all other windows open (this was previously failing with my last attempt)

autoclose_netrw=1, multi-file, single-window

Open multiple files in different buffers, but only a single window. Then open Tagbar and NERDTree. Then hit :q from the main window.

[ ] vim8.1: VIM warns that there is still an open file and prompts 'Are you sure' about closing. If y chosen, then vim quits, if n chosen, then main window closes, tagbar window closes, and netrw window is left open with both files in buffer list. This looks like a behavioral bug.
[ ] vim9.1: No warning seen, main window closes, tagbar window closes, netrw window is left with only one file still in the buffer list. We have a definite change in behavior here which we may not want to go with.

autoclose_netrw=1, single-file, single-window, file edited but not written

Open a single file. Then open Tagbar and NERDTree. Next edit the file, but don't write it. Then hit :q from the main window.

[ ] vim8.1: VIM warns that the file is not written and asks if you want to write it. If y chosen, file is written and vim quits. If n is chosen, file is not written and vim quits. If c (cancel) chosen, then main file window remains, tagbar window closes, netrw window closes
[ ] vim9.1: No warning seen, main window closes, tagbar window closes, netrw window left open with file buffer still open unwritten. Again a change in behavior that I don't know we can go with.

Summary

This is definitely better, however in the cases where VIM would normally prompt a warning about something (multiple buffers, unwritten changes, etc), we have a break in functionality where we no longer see the prompt and windows are closed leaving VIM in an odd state.

I think we can build on this though and see if we can address these remaining items, maybe even fix the undesired behavior on vim-8.x as well.

preservim / tagbar