This one generates a runtime/ file instead of a source file.
But otherwise it works the same like all other generators.
It has the same prerequisites (shared and mpack modules, etc), and,
importantly, it uses results from the source generators.

The odd location makes it easy to overlook when refactoring generators
(like I did last time, lol)

problem: the api of vim.mpack is not compatible with a system provided mpack
solution: don't require 'mpack' directly from the system path

Also don't highlight :def as vimCommand.

Problem:
Build is not reproducible, because generated source files (.c/.h/) are not
deterministic, mostly because Lua pairs() is unordered by design (for security).

https://github.com/LuaJIT/LuaJIT/issues/626#issuecomment-707005671
https://www.lua.org/manual/5.1/manual.html#pdf-next
> The order in which the indices are enumerated is not specified [...]
>
>> The hardening of the VM deliberately randomizes string hashes. This in
>> turn randomizes the iteration order of tables with string keys.

Solution:
- Update the code generation scripts to be deterministic.
    - That is only a partial solution: the exported function
      (funcs_metadata.generated.h) and ui event
      (ui_events_metadata.generated.h) metadata have some mpack'ed
      tables, which are not serialized deterministically.
    - As a workaround, introduce `PRG_GEN_LUA` cmake setting, so you can
      inject a modified build of luajit (with LUAJIT_SECURITY_PRN=0)
      that preserves table order.
    - Longer-term we should change the mpack'ed data structure so it no
      longer uses tables keyed by strings.

Closes #20124

Co-Authored-By: dundargoc <gocdundar@gmail.com>
Co-Authored-By: Arnout Engelen <arnout@bzzt.net>

Update runtime files
https://github.com/vim/vim/commit/8c1b8cb2e0b52d0853f85c2096a2f22dbc57a788

It's special cased by the vimSubst syntax group, and isn't present in Vim's
vimCommand group.

For example, this fixes `call s:Foo()` highlighting `:` as Error in Nvim, as the
`s` is parsed as vimCommand rather than as vimUserFunc since
`contains=vimCommand` was added to vimUserFunc (and vimFunc) in a rt update.

Interestingly, `g:`, `l:`, etc. have the same issues due to :global, :list, etc.
Vim also has that problem, so it should ideally be fixed upstream.

We could also omit g[lobal] from vimCommand and rely on vimGlobal instead, but
it doesn't work in some cases, like when there's a `:` before the command. Also,
Vim matches only `g` in vimCommand for some reason, which doesn't produce any
highlight for `:global/foo/bar` (with Nvim you at least get some highlights on
the `global` bit despite the leading `:`).

Also, remove special handling of :py3 in syntax/vim.vim, as the generator seems
to have no problems finding it.

"b" flag is required to read binary files on Windows. 
https://www.lua.org/pil/21.2.2.html

Problem:    Ex command info contains confusing information.
Solution:   When using the NOTADR flag use ADDR_OTHER for the address type.
            Cleanup code using NOTADR.  Check for errors in
            create_cmdidxs.vim.  Adjust Makefile to see the errors.
https://github.com/vim/vim/commit/b731689e85b4153af7edc8f0a6b9f99d36d8b011

Use Lua's "assert()" to make an invalid command definition
a compilation error.

Misc changes:

Remove 'RESTRICT' flag.
Neovim does not support "restricted" mode
since commit 7777532cebcfa9abc5ab2c7beae77f386feed3ca.

TODO:
Do not generate files before Lua assertions
so that CMake always runs the generator script
if the previous build has an invalid command definition.