Implements "extended registers"

Extended registers provide access to a separate namespace of registers
backed by custom lua callback functions.

A new special register ("~) is introduced, which prompts the user for
the name of an extregistr to yank or paste from.

This enables file-backed or cloud-synced or other arbitrary register
behavior.

One can now use:

`"~file_extreg<cr>yy`

to yank into the "file_extreg" register.

AI-assisted: Qwen3-Coder

This is a bunch of hacks so we can override msg_puts_printf specifically
while still allowing redirecting and "normal" message flow to happen,
as this still has observable side-effects (even with no screen attached,
screenstring() is still valid..)

fixes #42218

consider the following test_script.lua :

    print 'hello\n' -- TWO new lines
    print 'this is \027[31mRED FOR AN AMAZING REASON\027[0m'
    print 'foo'
    print '' -- newline despite empty!
    print 'bar'

    -- a bit later:
    os.execute 'sleep 2' -- CPU goes BRR, cursor in column zero
    print 'more bar'

before this PR, `nvim -l test_script.lua` had some weird behaviors
compared to `lua test_script.lua` or the now removed `nvim -ll
test_script.lua`.

- one extra '\n' at the end of a print is ignored, one would need
  TWO '\n' for a single extra '\n'

- an empty print'' is supposed to print an empty line

- print'\027[31mRED' is being escaped so it does not work

- the cursor gets stuck at the end of a message, instead of after
  emitting the new line, this looks like the CPU lag has something
  to do with the _last_ printed message which is likely not the case.

I consider these behaviors to be unintentional (a consequence of
stragglig through the message.c meta-machine, which is optimized
for message handling in _an interative text editor_) and getting
closer to plain lua behavior would be better.

An alternative would be to restore the builtin print(), but our
implemenation still has some benefits, like try
`print(setmetatable({}, {__tostring=error})` in plain lua..

Problem: Command inputs and parsed modifiers have different optional
fields, and completion window IDs are annotated as floating-point
values.

Solution: Separate modifier input and return types, correct integer IDs,
and update the metadata generators and their output.

AI-assisted

context: vim_snprintf provides a "portable" replacement for a system
vsnprintf(). However we rely on system vsnprintf() in places. This
is quite arbitrary. I want to use system vsnprintf() only, and
reduce the machinery in string.c for typval printf only, which will
delet a lot of duplicated code.

The biggest hurdle here is not "portably" (we only support sane c
runtimes) but the following discrepancy: standard libc printf()
considers NULL args to %s to be undefined behavior strictly
while vim_snprintf() _defacto_ allows this by replacement to "[NULL]"

IMO, this should be seen as "graceful" error handling (nicer than crashing
on the user), not a valid means to have the string "[NULL]" intentionally
be shoved in the users face. more robust code should explicitly
check for NULL and replace it with a _appropriate_ fallback for
the situation, depending on what a NULL string actually means in the
context (unnamed buffer? anonymous namespace? global augroup?)

soo, this PR provides the most _gently_ incremental nudge towards
considering this case again as an error one could possible imagine.
If sanitizers are complied in, this minor incursion gets printed
into the sanitizers' log as a "report-and-continue" error with a
traceback. This doesn't annoy the end user or "stop the world"
in the test suite, but the CI will see the reported error and
fail the build, just like other non-fatal CI errors.

Problem:
`nlua_pcall()` references `_G.debug.traceback`. If user code deletes it
or breaks it some other way, various Lua features are broken.

    _G.debug = nil
    vim.schedule(function() end)
    vim.wait(100)

    E5113: Lua chunk: attempt to index a nil value
    stack traceback:
            [C]: in function 'loop_poll'
            [string "vim/_core/editor"]:176: in function 'wait'
            crash.lua:3: in main chunk
    PANIC: unprotected error in call to Lua API (attempt to index a nil value)

Solution:
Check `_G.debug.traceback` before using it as errfunc. If it's broken,
omit the traceback and say so in the error message.

Note: We could cache `_G.debug` in LUA_REGISTRYINDEX on startup, but
that would prevent plugins from providing custom functionality there
(and we happen to do so in `tui_spec.lua` for example).

Problem:
Leak reported by ASAN CI, always at Lua state init.

      ERROR: LeakSanitizer: detected memory leaks
          strbuf_init src/cjson/strbuf.c:62:22
          json_create_config src/cjson/lua_cjson.c:635:5
          lua_cjson_new src/cjson/lua_cjson.c:2060:5
          nlua_state_add_stdlib src/nvim/lua/stdlib.c:840:3
          nlua_state_init src/nvim/lua/executor.c:973:3
      ...
      SUMMARY: AddressSanitizer: 1055 byte(s) leaked in 2 allocation(s).

Analysis:
`getout()` may run during `free_all_mem()` (that's why it checks
`!entered_free_all_mem`). If that happens, the second `os_exit()`
returns early from `free_all_mem()` then `exit()` is called and Lua
state is never closed.

Solution:
Always call `nlua_free_all_mem()` in the early-return case.