Problem:
Dirs "config", "packaging", and "third-party" are all closely related
but this is not obvious from the layout. This adds friction for new
contributors.

Solution:
- rename config/ to cmake.config/
- rename test/config/ to test/cmakeconfig/ because it is used in Lua
  tests: require('test.cmakeconfig.paths').
- rename packaging/ to cmake.packaging/
- rename third-party/ to cmake.deps/ (parallel with .deps/)

Problem: #19029 added a new fallback that sets
`$MACOSX_DEPLOYMENT_TARGET` to the local macOS version via `sw_vers`.
However, the output included a newline, which broke the generated Ninja
build script.

Solution: use `OUTPUT_STRIP_TRAILING_WHITESPACE` for `execute_process`.

CMake can handle building universal binaries on macOS using the
`CMAKE_OSX_ARCHITECTURES` variable. Let's pass this variable to the
relevant dep builds. We use the `LIST_SEPARATOR` argument to prevent the
shell from interpreting the `;` that CMake uses as a list separator.

For dependencies that don't build using CMake, we only need to make sure
that the compiler is invoked with the correct `-arch` flags. The
compiler does the rest.

The only exception to this is the LuaJIT build, which we handle
separately as a special case.

To build universal binaries on macOS, one typically only needs to pass
multiple `-arch` flags to `clang`.

Unfortunately, this strategy causes LuaJIT builds to fail. To work
around this, we build LuaJIT for each requested architecture
individually first and then use `lipo` to package each architecture
slice into a universal binary.

To be able to do this on an Intel macOS host or an M1 macOS host without
a Rosetta installation, we need some special flags in order to tell
LuaJIT that it is cross-compiling for a different target. See [1] for
details.

[1] https://luajit.org/install.html#cross

This is rarely, if ever, used and certainly not tested. It's likely this
isn't functional anymore.

This partially reverts commit f8af81445bb48966d54f4a956842d935d009d275.

The mingw parts of cmake was removed to see if it was still used
(ref: https://github.com/neovim/neovim/pull/18580). It turns out it is,
so this will fix that.

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

Unnecessary CI builds increase the change of spurious failures, which are costly
noise. Of course, we should fix all legitimate bugs, but we also cannot
micro-manage every platform, so there needs to be a clear motivation for the CI
builds that we maintain.

Reasons against maintaining a mingw CI job:
1. The windows mingw build is slow.
2. Failures:
    - https://github.com/neovim/neovim/issues/18494
    - https://github.com/neovim/neovim/issues/18495
3. The mingw artifact is 10x bigger than the windows MSVC artifact:
   https://github.com/neovim/neovim/issues/10560
4. Our releases publish the MSVC (not mingw) artifact for Windows users:
   https://github.com/neovim/neovim/releases
5. Non-MSVCRT has limitations documented by libuv: http://docs.libuv.org/en/v1.x/process.html
   > On Windows file descriptors greater than 2 are available to the child process only if the child processes uses the MSVCRT runtime.

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

this removes gperf as a build dependency