contrib: add a script to build all of the wheels on macOS This is mostly a translation of `contrib/packaging/build-windows-wheels.bat`, except the default pythons to build can be inferred from `setup.py` and/or `pyproject.toml`, and all use the same configuration. All we need to do is force the building of translation files, tell it to skip pypy wheels, and tell it to build universal2 wheels instead of for the current architecture.

rhg-status: rename a variable to be more explicit Possibly we would have caught the looming bug earlier if this had been named closer to what it actual is used for.

rhg-status: use `Filelog` default options when opening filelogs This is not currently a problem since the options are the same, but would have become one at some point in the future.

wheels: make sure we create the `dist/` directory in the make target The embarrassing details of how this was discovered will be kept under silence.

wheels: remove deprecated blacklist We no longer run the test while building wheels as they are build the very same ways as in the CI (that run tests).

contrib: add a bat file to build all of the wheels on Windows This is duplicated from the current CI config, to be able to build releases consistently outside of CI. I don't like the duplication, but I'm not worried about things changing too often, so I'm not bothering with PowerShell or some form that would allow execution by the CI runner. We should consider putting the config in `pyproject.toml`, where things like what python versions to support can be centrally controlled for all platforms. The output directory is different from CI here, but that's fine because it is intended to run this on a system that is *not* hosting the CI setup, and `dist/` is more standard. I dropped the `win32` part of the output because that implies the 32-bit Intel architecture. Apparently, arm64 builds are supported back to Python 3.9, but support is still experimental (with py3.13)[1]. The CI system starts arm64 support with Python 3.11, because that's the first version that an arm64 Python installer was available on Windows. This doesn't second guess that decision. The required `msgfmt.exe` was installed manually[2], as it isn't currently handled by the dependency installation script. Otherwise, this was successfully used with an activated venv based on Python 3.12.5, and only `cibuildwheel==2.21.3` installed. [1] https://cibuildwheel.pypa.io/en/stable/#what-does-it-do [2] https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.22.5a-v1.17-r3/gettext0.22.5a-iconv1.17-shared-64.exe

contrib: install the arm64 compiler tools in the Windows dependency script This lets us build arm64 wheels on Windows. We should update from VS 2017 to VS 2019, but that can wait until there's a clean Windows system available. There's a little bit of handwaving here because I originally installed some packages on the CI system by checking boxes in the GUI installer to get arm64 support, since I didn't know the name(s) of the things needed. Exporting the configuration from the GUI installer showed the list of things present, and then I was able to run `vs_buildtools.exe` on another system that previously had this dependency script run a few years ago, with just this new arg. That allowed the wheels to be built (the process failed on this second system prior to this). The only difference between the CI system configuration prior to installing arm64 stuff and this second system after, is the second system has the WinXP support component. Surprisingly, the arm64 WDK and arm64 CRT or Universal CRT doesn't seem to be required.