MAINT: use ruff instead of black, flake, isort

[theroggy]

Many projects move to ruff for linting/formatting because:

• you only need one tool for all python linting/formatting as it supports a huge amount of rules
• it is fast
• supports many automatic fixes
• very actively developed

Maybe a good idea to transition exactextract linting and formatting to it as well?

I enabled/configured the rules based on the rules used in shapely.

Remark: I temporarily excluded some pydocstyle rules before continuing work on this as it is some more work to add some more missing docstrings... and I'd rather wait to put in that effort till there is confirmation that this is a good idea ;-).

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 91.89189% with 3 lines in your changes missing coverage. Please review.

Project coverage is 91.02%. Comparing base (3149ffd) to head (d98927f).

Files with missing lines	Patch %	Lines
python/src/exactextract/operation.py	75.00%	2 Missing :warning:
python/src/exactextract/writer.py	90.00%	1 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #152 +/- ## ========================================== - Coverage 91.05% 91.02% -0.04% ========================================== Files 85 85 Lines 6429 6438 +9 Branches 628 628 ========================================== + Hits 5854 5860 +6 - Misses 543 546 +3 Partials 32 32 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[dbaston]

Hi @theroggy . The current setup is copied from GDAL. I can appreciate that it's not state-of-the-art, but given that this is a pretty small project, my initial thought is to stick with it unless I understand a more clear advantage to switching.

[theroggy]

In general "as much linting as possible" is a good idea I think, especially with an interpreted language like Python, and ruff makes this quite easy.

The reason I thought about it was actually that I noticed when starting to use exactextract in a project (cropclassification), that it isn't marked as typed for mypy... I created this PR mainly as being maybe a good first step to "upgrade" the linting... Next, the type annotations already present could be expanded where possible/useful so py.typed could be included. This way projects using exactextract can have mypy checks on the integration.

Also note that ruff mainly tries to mimic the functionalities of the most popular linting/formatting tools like black, flake, isort... and the many "plugins" that exist for these tools. So e.g. for the formatting, it is 99.9% compatible with black (ruff faq).

I am personally fan of checks on the docstrings (using the "pydocstring" tests), to make sure each function and each parameter is (and stays) properly documented. Even in exactextract there are quite some functions/parameters that are not documented...

For GDAL I think it would be a very good idea as well to have more linting, especially on the docstrings. The effort there to get everything in line would obviously be another story than for exactextract... but maybe exactextract can act as a pilot to get some experience with it? Note that it is also possible to just use ruff "barebones", so it just does the same as black / basic flake8, and it is then possible to activate more and more rules via the myproject.toml file in incremental steps.