Release binary package for python 3.12

[jesper-friis]

Description

Release binary wheels for python 3.12. Added releases for the following new versions and systems:

• manylinux2014 i686: Python 3.10 - 3.12

• musllinux_1_1 i686: Python 3.10 - 3.11

• manylinux2014 x86_64: Python 3.10 - 3.12

• manylinux_2_28 x86_64: Python 3.7 - 3.12

• musllinux_1_1 x86_64: Python 3.10 - 3.11

• win amd64: Python 3.12

Documented and extended the total range of of supported systems and Python versions.

Note that resent versions of Alpine uses musllinux_1_2 and that Python 3.12 is not supported by musllinux_1_1. Therefore, this PR add (so far untested) support for musllinux_1_2 by including it in the weekly built docker container. When merged to master, it is possible to run the weekly container build. If that works, we can create a new PR that adds musllinux_1_2 to the release.

After the weekly container successfully has run (which can be triggered manually), a new release should be made to make the wheel for Python 3.12 available on PyPI.

Type of change

• Bug fix & code cleanup
• New feature
• Documentation update
• Test update

Checklist for the reviewer

This checklist should be used as a help for the reviewer.

• Is the change limited to one issue?
• Does this PR close the issue?
• Is the code easy to read and understand?
• Do all new feature have an accompanying new test?
• Has the documentation been updated as necessary?

[torhaugl]

Looks good to me. I added a small suggestion for the windows versioning to improve readability, but it is not strictly neccessary. We should check that everything works correctly for python 3.12 using pip install DLite-Python when it is uploaded there as well.

[torhaugl]

Can the windows releases be combined into one, similar to the linux ones?
py_minors: 7,8,9,10,11,12

[jesper-friis]

I don't know. I have just assumed that there is a reason why they were separated initially.

We should check it out, it just takes a lot of time to wait for the wheel to be build... but we have already done a lot of changes in this PR that first can be really tested when we run the weekly build after the PR is merged. Hence, I would prefer to test out things like that in a separate PR to simplify debugging is it turns out that something is wrong.