Problem:  nvim_eval_statusline() uses "stl" from 'fillchars' with "use_statuscol_lnum".
Solution: Reorder "fillchar" else chain.

Minor "best practices" nudge.

Getting current channel info was kind of annoying via RPC. Two
functions had to be called:
1. `nvim_get_api_info` which returns `[channel_id, meta_data]`.
  - This results in `channel_id = api.nvim_get_api_info()[0]`.
  - Here the meta_data is sent but never used.
2. Finally call `nvim_get_chan_info(channel_id)`.

This commit reduces the need for `nvim_get_api_info` as passing 0
returns current channel info.

Problem:
When nvim_input is followed immediately by non-fast events on RPC, both
events and input are available after the polling done by the os_inchar()
in state_enter(), but state_enter() then chooses to process events even
if input is available, which is inconsistent with state_handle_k_event()
that stops processing events once input is available.

Solution:
Also check for available input after the os_inchar() in state_enter().

Adds support to `nvim_open_win` and `nvim_win_set_config` for creating
and manipulating split (non-floating) windows.

Allows setting the current window of a non-current tabpage
without switching tabpages.

The "priority" field of extmarks can be used to set priorities of
extmarks which dictates which highlight group a range will actually have
when there are multiple extmarks applied. However, when multiple
extmarks have the same priority, the only way to enforce an actual
priority is through the order in which the extmarks are set.

It is not always possible or desirable to set extmarks in a specific
order, however, so we add a new "subpriority" field that explicitly
enforces the ordering of extmarks that have the same priority.

For now this will be used only to enforce priority of treesitter
highlights. A single node in a treesitter tree may match multiple
captures, in which case that node will have multiple extmarks set. The
order in which captures are returned from the treesitter API is not
_necessarily_ in the same order they are defined in a query file, so we
use the new subpriority field to force that ordering.

For now subpriorites are not documented and are not meant to be used by
external code, and it only applies to ephemeral extmarks. We indicate
the "private" nature of subpriorities by prefixing the field name with
an "_".

Problem:  Things that temporarily change/restore curwin/buf (e.g:
          win_execute, some autocmds) may break assumptions that
          curwin/buf is the cmdwin when "cmdwin_type != 0", causing
          issues.

Solution: Expose the cmdwin's real win/buf and check that instead. Also
          try to ensure these variables are NULL if "cmdwin_type == 0",
          allowing them to be used directly in most cases without
          checking cmdwin_type. (Sean Dewar)

Reset and save `cmdwin_old_curwin` in a similar fashion.
Apply suitable changes for API functions and add Lua tests.

https://github.com/vim/vim/commit/988f74311c26ea9917e84fbae608de226dba7e5f