perf(vim.fn): call Lua-implemented vim.fn.xx() directly #39166

Problem:
- Builtin "Vimscript" functions (f_xx) are mostly implemented in C.
  Partly that's because there is some boilerplate required to call out
  to Lua.
- Calls to `vim.fn.foo()` always marshall over the Lua <=> Vimscript
  ("typval") bridge, even if `fn.foo()` is implemented entirely in Lua:
  ```
  Lua => typval => Object => Lua => Object => typval => Lua.
  ```

Solution:
Functions declared in eval.lua with `func_lua` are implemented in
entirely in Lua (`_core/vimfn.lua`).

- `gen_eval.lua` wires `func_lua` entries to `lua_wrapper`, which handles
  the typval conversion for Vimscript callers (slow path).
- `nlua_call()` detects `func_lua` functions and calls the Lua
  implementation directly. This eliminates all conversion overhead for
  Lua callers (fast path).
- Validate at build-time that `func`, `func_float`, and `func_lua` are
  mutually exclusive.
- Migrate `hostname()` as a toy example, to show the idea.

runtime/lua/vim/_core/vimfn.lua

@@ -0,0 +1,14 @@
+-- Lua implementations of "vimfn" builtin functions (via `func_lua`).
+--
+-- Functions defined here are pure Lua, they don't have any explicit C impl, so they are named with
+-- the "f_xx" convention, for discoverability.
+
+local M = {}
+
+--- Returns the hostname of the machine.
+--- @return string
+function M.f_hostname()
+  return vim.uv.os_gethostname()
+end
+
+return M

runtime/lua/vim/_meta/vimfn.gen.lua

@@ -4475,8 +4475,7 @@ function vim.fn.hlID(name) end
 function vim.fn.hlexists(name) end
 
 --- Returns the hostname of the machine on which the Nvim server
---- (not the UI client) is currently running.  Names greater than
---- 256 characters long are truncated.
+--- (not the UI client) is currently running.
 ---
 --- @return string
 function vim.fn.hostname() end