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.

restore mingw in cmake