Notes:
- 8.2.1614 also flips searchcount()'s "recompute" default to FALSE;
- 8.2.1620 flips it back, so the default stays true here.

vim-patch:8.2.1601: Vim9: cannot use 'true" with garbagecollect()
https://github.com/vim/vim/commit/2df47310422f4a77e85de7901a5299923a1addd3

vim-patch:8.2.1602: Vim9: cannot use 'true" with getbufinfo()
https://github.com/vim/vim/commit/036c2cf719e3de445779a275514030be66e26883

vim-patch:8.2.1603: Vim9: cannot use "true" with getchar()
https://github.com/vim/vim/commit/c08cc72947fdfab484f53c5d9bbea662bc5a9c8f

vim-patch:8.2.1604: Vim9: cannot use "true" with getcompletion()
https://github.com/vim/vim/commit/d217a87755ba01fc626b1c178c682fcd05ab3a28

vim-patch:8.2.1614: Vim9: cannot pass "true" to searchcount()
https://github.com/vim/vim/commit/597aaac9d2b090e0eb738ab4e2afd454b7b92393

vim-patch:8.2.1615: Vim9: cannot pass "true" to searchdecl()
https://github.com/vim/vim/commit/30788d3d37a90b0702d94b7272ed26672534ba6f

vim-patch:8.2.1616: Vim9: cannot pass "true" to synID()
https://github.com/vim/vim/commit/fcb6d7082d563acc33866b3d3a659c32ad19a9e1

vim-patch:8.2.1617: Vim9: cannot pass "true" to win_splitmove()
https://github.com/vim/vim/commit/4b9bd692bdffba03fda04f9979e25431b53e416b

vim-patch:8.2.1619: Vim9: cannot pass "true" to spellsuggest()
https://github.com/vim/vim/commit/7c27f337bf278babc1ccdcb66ac975f115d660b7

vim-patch:8.2.1620: searchcount() test fails
https://github.com/vim/vim/commit/4140c4f3fff1a441f2837f2f911ab0f0368e412a

N/A patches:
vim-patch:8.2.1606: has() takes no second argument in Nvim
https://github.com/vim/vim/commit/04637e243d39f791cfc97c3ce96d99ef1bf047e1
vim-patch:8.2.1610: list2str()/str2list() take no "utf8" argument
https://github.com/vim/vim/commit/a48f786787e8e070c1a611146fd1f0f7e141e60a
vim-patch:8.2.1611: nr2char() ignores its "utf8" argument
https://github.com/vim/vim/commit/ed6a430fae72c077ec106c9620379b69cfec3035

Problem:    The channel source file is too big.
Solution:   Move job related code to a new source file.

----

Move eval-related prompt-buffer API to src/nvim/nvim/eval/buffer.c.

https://github.com/neovim/neovim/pull/37743#issuecomment-3897416840

----

https://github.com/vim/vim/commit/8b5866ded6036f7adece26b6d16962bbd2d47842

Co-authored-by: Bram Moolenaar <Bram@vim.org>

Problem:    Vim9: bufnr() doesn't take "true" argument.
Solution:   use tv_get_bool_chk(). (closes vim/vim#6863)

https://github.com/vim/vim/commit/fe136c9a85412f4bdb5de70ef8416af5fa382b28

Co-authored-by: Bram Moolenaar <Bram@vim.org>

Problem:    Vim9: bufname('%') gives an error.
Solution:   Only give an error for wrong argument type. (closes vim/vim#6807)

https://github.com/vim/vim/commit/02aaad91094939758e053588dd23ebda467eea29

Co-authored-by: Bram Moolenaar <Bram@vim.org>

Problem:    ml_get error when changing hidden buffer in Python.
Solution:   Block updating folds. (closes vim/vim#7598)

----

"ctx_switch()", "ctx_restore()" obsolete "switch_buffer()" and
"restore_buffer()".
Latter are unused since https://github.com/neovim/neovim/pull/15831.
Mark them as N/A (until some test fails).

----

https://github.com/vim/vim/commit/3e0107ea16349b354e0e9712e95b09ef019e99e5

Co-authored-by: Bram Moolenaar <Bram@vim.org>

Problem:
- `edit.c` is an unnecessarily misleading and less-discoverable name
  than `insert.c`.
- Numerous insert-mode related things are named with a `ins_` prefix.
- There is already a `insexpand.c` module...

Solution:
Rename `edit.c` => `insert.c`.

Problem:

cmdwin (the `:q` cmdline buffer) has various limitations which require
special-casing all over the codebase.

Besides complicating the code, it also breaks async plugins if they try
to create buffers/windows after some work is done, if the user happens
to open cmdwin at the wrong the moment:

    Lua callback: …/guh.nvim/lua/guh/util.lua:531:
    E11: Invalid in command-line window; <CR> executes, CTRL-C quits
    stack traceback:
        [C]: in function 'nvim_buf_delete'
        …/guh.nvim/lua/guh/util.lua:531: in function <…/guh.nvim/lua/guh/util.lua:526>

Solution:

Just say no to "inception". Reimplement cmdwin as a normal buffer+window.

All of the cmdwin contortions (in both core, and innocent plugins) exist
literally only to support "inception": recursive
cmdwin-in-cmdline-things, like `<c-r>=`, `/`, search-during-substitute,
`:input()`, etc. So we just won't support that (though I have
a potential plan for that later, which I call "modal parking lot").

The benefit is that plugins, and core, no longer have to care about
cmdwin.

BONUS:
- mouse-drag on vertical separators works (it only worked for
  horizontal/statusline before)
- inccommand-in-cmdwin now works correctly, for free (thus don't need
  #40077).

POTENTIAL FOLLOWUPS
- Drop `CHECK_CMDWIN` ("E11: Invalid in command-line window"), allow chaos.
- Unify `BUFLOCK_OK` / `LOCK_OK` ?

DESIGN:
- Eliminate lots of C globals, `EX_CMDWIN`, etc.
- `text_locked()` no longer reports true for cmdwin.
- cmdwin = a normal window with 'winfixbuf', 'bufhidden=wipe',
  'buftype=nofile'. Invariants come from those options rather than
  special cases throughout the codebase.
- `nv_record` for q:/q//q? calls Lua
  `nlua_call_vimfn("vim._core.cmdwin", …)`. No `K_CMDWIN`
  / cmdline-reader detour.
- `cedit_key` (`c_CTRL-F`) schedules a deferred event that calls
  `vim._core.cmdwin.open(type, content, pos)` and returns `Ctrl_C` so
  the in-flight cmdline cancels. Reader state is not serialized; instead
  the captured `(type, line, col)` is replayed via
  `nvim_feedkeys(type..line.."<CR>", "nt", …)` after user confirms.
- On confirm/cancel: `<CR>` / `<C-C>` calls into Lua which closes the
  window and re-feeds the cmdline.

BREAKING CHANGES:
- Expression-register cmdline (`<C-R>=` from insert-mode) no longer
  supports cmdwin. Same applies to `input()` / `inputlist()` (already
  covered by `text_locked`).
- Usage of cmdwin in macros/mappings will probably break (assuming they
  ever worked).

Problem:    Vim9: Getbufline(-1, 1, '$') gives an error.
Solution:   Return an empty list. (closes vim/vim#7180)

https://github.com/vim/vim/commit/e6e70a10f118ecfa9df2425e8724bc009bd09929

Co-authored-by: Bram Moolenaar <Bram@vim.org>