Problem:
The magic globals `it`, `describe`, etc., are more trouble than they are
worth.

- Hooking into `after_each` requires `getfenv()` hacks.
- They confuse luals/emmylua, because the top-level `.luarc.json` isn't
  merged with `test/.luarc.json` (apparently a luals limitation?)
- They totally defeat discoverability because the user just has to
  "know" about the various magic symbols.

So they harm DX, which means they serve no purpose at all.

Solution:
- Expose the test API from `testutil`, so tests can call `t.it()`,
  `t.describe()`, etc., in the conventional way.
- Drop `getfenv()` hacks.
- Drop the `setfenv()` injection in `load_chunk`.
- Drop `test/_meta.lua`.

problem:
this crashes neovim:

ondska = setmetatable({}, {__tostring = error})
error(ondska)

solution:

make it not crash neovim

Problem:
The "gitsigns" plugin runs `vim.diff` in a thread (`uv.new_work`), but
`vim.diff` is nil in that context:

    Lua callback:
    …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: bad argument #1 to 'decode' (string expected, got nil)
    stack traceback:
      [C]: in function 'decode'
      …/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: in function <…/gitsigns.nvim/lua/gitsigns/diff_int.lua:29>
    Luv thread:
    …/gitsigns.nvim/lua/gitsigns/diff_int.lua:63: attempt to call field 'diff' (a nil value)

Solution:
Revert the `stdlib.c` change (set `vim.diff` instead of `vim._diff`).

Problem:
Since renaming `vim.diff` to `vim.text.diff`, `thread_spec.lua` fails in
the zig build. Is `vim.text.diff` not available in the thread context?
Why does it only fail in the zig build?

    FAILED   ./test/functional/lua/thread_spec.lua @ 217: thread vim.* diff
    ./test/functional/lua/thread_spec.lua:229: Expected objects to be the same.
    Passed in:
    (nil)
    Expected:
    (table: 0x7f221d392218) {
      [1] = 'notification'
    E5113: Lua chunk:
      [2] = 'result'
      [3] = {
        [1] = '@@ -1 +1 @@
    -Hello
    +Helli
    ' } }

    stack traceback:
            ./test/functional/lua/thread_spec.lua:229: in function <./test/functional/lua/thread_spec.lua:217>

    FAILED   ./test/functional/lua/thread_spec.lua @ 372: threadpool vim.* work
    ./test/functional/lua/thread_spec.lua:384: Expected objects to be the same.
    Passed in:
    (table: 0x7f2225be2c30) {
      [1] = 'notification'
      [2] = 'result'
     *[3] = {
       *[1] = vim.NIL } }
    Expected:
    (table: 0x7f2225be25c0) {
      [1] = 'notification'
      [2] = 'result'
     *[3] = {
       *[1] = '@@ -1 +1 @@
    -Hello
    +Helli
    ' } }

    stack traceback:
            ./test/functional/lua/thread_spec.lua:384: in function <./test/functional/lua/thread_spec.lua:372>

Solution:
Use `vim._diff` in the test, until a root cause is found.

Problem:
`vim.diff()` was introduced before we had the `vim.text` module, where
it obviously belongs.

Solution:
Move it.

"Error" in error messages is redundant. Just provide the context, don't
say "Error ...".

Problem:
Calling `xstrdup` with a NULL pointer causes a SIGSEGV if `lua_tostring` returns
NULL in `nlua_luv_thread_common_cfpcall`.

Crash stack trace:
- `_platform_strlen` → `xstrdup` (memory.c:469)
- `nlua_luv_thread_common_cfpcall` (executor.c:281)

Solution:
Check if `lua_tostring` returns NULL and pass NULL to `event_create` to avoid the crash.

Before calling "attach" a screen object is just a dummy container for
(row, col) values whose purpose is to be sent as part of the "attach"
function call anyway.

Just create the screen in an attached state directly. Keep the complete
(row, col, options) config together. It is still completely valid to
later detach and re-attach as needed, including to another session.