fix(lua): regression with `print()` in headless mode when redirecting

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

Problem:
`vim._with({ buf = 0, win = 0 }, f)` fails an assert in ctx_switch().
vim._with() allows `buf` with `win` when `win` shows `buf`, but
nlua_with() passes both, and ctx_switch() takes only one target.

Solution:
Ignore `buf` if `win` is given; the window implies its buffer.

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

CI is currently using clang-tidy 21 but prepare for the future

Problem: Option validators and setters repeatedly pass error buffers and
their sizes separately. Some setters return messages in static storage.

Solution:

- Add CharBuf for borrowed writable storage, with its length including
  space for a terminating NUL.
- Move option error buffers to the callers that report errors. Preserve
  existing buffer sizes, truncation, and calls that do not need a
  message.
- Consolidate option error formatting and the duplicated code that lists
  valid option values.
- Return error messages directly from do_one_set_option().
- Remove unused arguments from get_option_newval() and
  set_option_value_for().
- Handle legacy TTY assignments in the existing callers and remove the
  redundant compatibility wrapper.
- Reuse CharBuf for Tree-sitter query errors.
- Pass CharBuf through the statusline and statuscolumn builders,
  retaining the buffer sizes provided by their callers, including title
  formatting.

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).

Co-authored-by: darkdi <rantovov5@gmail.com>
Co-authored-by: Qiaoxi Guo <28090444+breadtitor@users.noreply.github.com>
Co-authored-by: zaveshaa <zaveshaa@gmail.com>