Moved the metadata into `setup.cfg`

[KOLANICH]

Added pyproject.toml. Version is now populated automatically from git tags using setuptools_scm. Deleted bumpversion.sh. Fixed some missing metadata fields.

[JeffLIrion]

I've never used a setup.cfg file before, what is the benefit over using setup.py?

Also, the CI checks did not pass.

[KOLANICH]

I've never used a setup.cfg file before, what is the benefit over using setup.py?

No strong benefits currently:

• it is still possible to organize package vendor-supplied code execution while building a package with setup.cfg + pyproject.toml, but it was discussed that the long-term goal is to eliminate package vendor-supplied code execution in this case
• even more, soon setup.cfg will deprecated and its contents should be recommended to be moved into pyproject.toml (currently there is no automatic convertor setup.cfg -> pyproject.toml, but it will be more automatic, more secure and more reliable because of more constrained and parseable structure of setup.cfg, than setup.py -> setup.cfg, I guess even a bot automatically sending PRs will be possible).

[JeffLIrion]

From some brief reading, it looks like pyproject.toml is the way of the future. So if you get the CI checks to pass and once I understand how it works, I'll merge this.

[KOLANICH]

1. I have fixed the scripts to take the version from git tags and to update it. It will only work if there are commits upon the previous tag. Otherwise one should use the retag script.
2. I have cleaned up the scripts a bit. Some used to be determining package name and then discarding it. That code has been removed.

I haven't used GitHub Actions to upload an artifact. What's the benefit of doing so?

Not really a strong benefit, but sometimes allows you to get the artifact build on the CI. Can have various uses, from not-building the package as a part of other CI pipelines and using the wheel, to troubleshooting the issues on CI.