Another workaround for the utterly broken gui detection in nvim

Of course GUI detection wasn't fucked up enough in neovim already (see
c2603e4 for the last rant about this
topic). Instead of requiring special handling just for neovim, we now
also need special treatment just for neovim 0.9, because of course they
don't adhere to their own documentation anymore and v:event['chan'] may
now also return 1, as a sideeffect of running the internal TUI in a
separate process [0].

So to this day there is still no sane way to detect TUI in neovim,
instead we have to add a hacky workaround to check nvim_list_uis() for
ext_termcolors, which I am 100% confident will break in the future too.

Vim had sane API for this since forever and it is as simple as checking
for has('gui_running') at any point of time, but of course neovim can't
have this set at startup because we have to make everything convoluted
as fuck by sourcing plugins before the UI has a chance to attach.

Why the UI is not allowed to set a flag as the very first thing in the
startup sequence (and then attach later), is beyond stupid.

This is also not the first time that neovim's weird startup sequence
causes problems [1].

Fixes #46

[0] neovim/neovim#18375
[1] neovim/neovim#19362

Author: vimpostor

autoload/tpipeline/util.vim

@@ -16,7 +16,7 @@ func tpipeline#util#set_size()
 endfunc
 
 func tpipeline#util#check_gui()
-	if v:event['chan'] || has('gui_running')
+	if (v:event['chan'] && !(has('nvim-0.9') && nvim_list_uis()[0].ext_termcolors)) || has('gui_running')
 		call tpipeline#state#restore()
 	endif
 endfunc