In the api_info() output:

    :new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val')
    ...

    {'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1}

The `ArrayOf(Integer, 2)` return type didn't break clients when we added
it, which is evidence that clients don't use the `return_type` field,
thus renaming Dictionary => Dict in api_info() is not (in practice)
a breaking change.

Problem:

Tests have lots of exec_lua calls which input blocks of code
provided as unformatted strings.

Solution:

Teach exec_lua how to handle functions.

Specifically, functions that are run in the context of the test runner
are put in module `test/testutil.lua` while the functions that are run
in the context of the test session are put in
`test/functional/testnvim.lua`.

Closes https://github.com/neovim/neovim/issues/27004.

Work on https://github.com/neovim/neovim/issues/27004.

When we convert a Lua table to an Object, we consider the table a
"dictionary" if it contains only string keys, and an array if it
contains all numeric indices with no gaps. While rare, Lua tables can
have both strictly numeric indices and gaps (e.g. { [2] = 2 }). These
currently cannot be serialized because it is not considered an array.

However, we know the maximum index of the table and as long as all of
the keys in the table are numeric, it is still possible to serialize
this table as an array. The missing indices will have nil values.

Currently (as of nvim 0.9), the behavior of boolean params in
vim.api lua wrappers is inconsistent for optional parameters
(part of an `opts` dict) compared to positional parameters.

This was inadvertently changed in #24524 . While cleaning up this
inconsistency is something we might want eventually, it needs
to be discussed separately and the impact of existing code considered.