avoid bogus naming of the macos wheels as universal2 despite intel-only

[slayoo]

No description provided.

[slayoo]

Nope, didn't help, still the following files are produced:

dist/PyPartMC-0.9.0.post4-cp310-cp310-macosx_12_0_x86_64.whl
dist/PyPartMC-0.9.0.post4-cp311-cp311-macosx_12_0_universal2.whl
dist/PyPartMC-0.9.0.post4-cp37-cp37m-macosx_12_0_x86_64.whl
dist/PyPartMC-0.9.0.post4-cp38-cp38-macosx_12_0_x86_64.whl
dist/PyPartMC-0.9.0.post4-cp39-cp39-macosx_12_0_x86_64.whl

?

[slayoo]

@zdaq12 this one addresses the issue of publishing macOS binary packages labelled as universal2 (i.e., with binaries for both Intel and ARM CPUs in single file) but containing actually only x86_64 binaries inside.

I haven't found the cause of this issue (which is present only for Python 3.11), so this PR proposes to manually "fix" these files before uploading by renaming the .whl files and altering the metadata inside (the WHEEL file).

For the record, the wheel format is described here: https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-format

It is tricky to test it before merging. After merging, there should be no more universal2 files uploaded to test.pypi.org for a given release (and to the main pypi.org after the next release).