MNT: switch to pyproject.toml, PEP-518 build system and improve CI

[theOehrly]

This pull request

• fully removes setup.py and setup.cfg in favour of the new pyproject.toml configuration file
• migrates to the new Python packaging system according to PEP-518 (using the hatchling build backend)
• introduces automatic semantic versioning from vcs using setuptools_scm
• changes how FastF1 internally gets its current version
• adds a minimum versions CI test
• migrates from flake8 to ruff for linting

TBD:

• Upgrade contributor docs to reflect changes
• clean up changes to workflows once the changes to the packaging system are final

[theOehrly]

@daylinmorgan if I remember correctly, the conda-forge package relies on the source distribution. Can you verify that the changes here don't cause any issues? I have uploaded a developement release to the PyPI test index (https://test.pypi.org/project/fastf1/3.2.0.dev35/) using the new automated release process. Can you use that for testing? Else, what do you need?

@pbulsink @SCasanova I don't know how the R wrapper interacts with FastF1. Is there any potential for issues here? There are no API changes. How FastF1 internally provides the fastf1.__version__ property has changed, but that should not have external consequences.

In case anyone wants to install the development release, use the following commands to install using pip:

pip install --upgrade fastf1  # ensures up to date dependencies from the main index
pip install -i https://test.pypi.org/simple/ fastf1==3.2.0.dev35 --no-deps

Alternatively, you can download the wheel build or a source distribution from the PyPI test index (see link above).

[pbulsink]

We do have a version check that I think uses fastf1.__version__, I'll have a look and report back (hopefully <48h). It should be an easy change to use any other syntax as a backup if __version__ doesn't work.

[theOehrly]

We do have a version check that I think uses fastf1.__version__, I'll have a look and report back (hopefully <48h). It should be an easy change to use any other syntax as a backup if __version__ doesn't work.

If it doesn't work, that would likely be an issue on my side. But please have a look at it so we could figure out any issues already.

[daylinmorgan]

Great work! These changes should have no effect on the conda-forge packaging.

[pbulsink]

No change in how things worked for f1dataR on dev:

> get_fastf1_version()
$major
[1] 3

$minor
[1] 2

[theOehrly]

Great, thank you both for checking!