python: Update black to 24.4.0

[echoix]

Updates black to the latest version, in the GitHub Actions workflows and pre-commit config.
Includes formatting for Jupyter notebooks too, since it is supported since version 21.8b0.

The specific changes in the configuration are made in different commits:

• Require version (pyproject.toml): Black allows setting a version, and will error out if not the correct one used. Since it accepts a more general version (rather than the full version), and that Black mentions it follows their stability policy, setting "24" will ensure all users are formatting with a version that will output the same style. It should solve the cases where contributors weren't using the same black version as was required in CI.
• Target version (pyproject.toml): Black can make some choices when it knows all python versions that the project should support. It is now set for supporting Python 3.8 through Python 3.12 (removed Python 3.7)
• Extend-exclude (pyproject.toml): Instead of setting exclusion patterns explicitly, keep black's good defaults, and only add python/libgrass_interface_generator/. In addition of common exclusions, black excludes all paths listed in .gitignore. The way the setting was made looks like an older suggested config. We are now aligned with the current recommendations.
• Include (pyproject.toml): The include pattern was overriding black's default include pattern, that was changed since the config file was written, thus Jupyter notebooks weren't formatted even if the feature was installed and available, and pre-commit was fixing them. Now, we only use the default include pattern (deleting the config line).

The files are formatted with the new version in the last commits, the next-to-last commit is for all files in the repo (171 files changed), and the last commit for the 9 Jupyter notebooks that had changes. I separated them for easier review (for looking at only one file at a time).

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[echoix]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

This is because the name of the configuration includes all the matrix variables. We could eventually rework the workflow to not have this every time a version changes, and not have a new "configuration" that will pile up (in the second screenshot) and be orphaned.

[echoix]

Most of the changes are adding a blank line between the file's docstring and the code, or removing an extra blank between it. There's only like a dozen or so "real" changes in the .py files.

[echoix]

I continued and made some tests using ruff format basing myself from these changes. Unfortunately, there was some files changed between both, in multiple ways.

Versions:
black: 24.3.0, with jupyter feature
ruff format: 0.3.4

Contents of this PR (black 24.3.0) + ruff format: 79 changed files. (includes libgrass_interface_generator)
Contents of this PR (black 24.3.0) + ruff format --target-version py38: 55 changed files. (excludes libgrass_interface_generator)
but most importantly,
Contents of this PR (black 24.3.0) + ruff format + black 24.3.0: 79+26 changed files (26 more, total 54 files (so some are reverting themselves)). (includes libgrass_interface_generator)
Contents of this PR (black 24.3.0) + ruff format --target-version py38 + black 24.3.0: 55+26 changed files (26 more, total 30 files (so some are reverting themselves)) (excludes libgrass_interface_generator)

Is the black preview style better?
Contents of this PR (black 24.3.0) + ruff format + black 24.3.0 --preview: 79+31 changed files (31 more). (includes libgrass_interface_generator)
Contents of this PR (black 24.3.0) + black 24.3.0 --preview: 24 changed files
Contents of this PR (black 24.3.0) + black 24.3.0 --preview + ruff format: 24+61 changed files (61 more) (includes libgrass_interface_generator)
Contents of this PR (black 24.3.0) + black 24.3.0 --preview + ruff format . --target-version py38: 24+61 changed files (61 more) (includes libgrass_interface_generator)
Contents of this PR (black 24.3.0) + ruff format . --target-version py38: 24+61 changed files (61 more) (includes libgrass_interface_generator)

Ruff preview style has way more changes, I didn't bother writing the results down.

Some of these changes could be solved once for both formatters, since some of the differences is some missing/extra blank lines around some comments/docstring at the beginning of the files that black 24 didn't fix, or some tabulations in the copyright headers changed to spaces. Most of the other differences are because of comments at the end of a line instead of before a line, which forces unnatural parenthesis to have the comment at the end of the last line. Sometimes I find that ruff made better choices, sometimes black. When the comment at the end of the line isn't a linter instruction (like # pylint: disable=W0612), then it would be possible to move the comment above and probably have both agree.

However, there are still some differences that ruff makes the same choices that were made with the black version before this PR.
So, in any case, when we would be ready to use the ruff as a formatter (ruff as a linter doesn't matter here, ruff does ruff check . and ruff format .), we would need to decide on which tool to use. Ruff is faster.

[echoix]

Have to update the PR, applying the changes, since it was waiting too long and the repo had other PRs merged meanwhile

[echoix]

Updated the new files and set the black version to the 24.4.0 release

[wenzeslaus]

Thanks for the overall update. The config was indeed dated since it was from the beta version times. Yes, notebooks should be formatted too.

The formatting changes indeed improve the formatting in most cases with couple cases being a neutral change for those specific lines. I added the add ref ignore label.

[echoix]

I see that the rebase this morning brought some other changes that happened since the weekend. I'll need to repost the changed files and will need a new approval

[echoix]

@wenzeslaus Can you reapprove after the single change in wxplot/profile.py change?

[echoix]

Once merged, PRs that change python code should be brought up to date in order to not have the workflow fail on main, and have the suggestions shown in the PR (if possible).

[echoix]

The PRs merged yesterday after my rebase didn't have problems with black 24.4 finally.

[echoix]

Can we regive it a go? it was approved 5 days ago on a failing CI check, that is fixed and kept updated.