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