ci: use Ruff for Python quality checks

[okt-limonikas]

We have a lot of tools for handling formatting, quotes etc, do pre-commit checks etc.
Black and ruff have conflicts currently so CI is almost always in failed state in each new PR.

We should just use ruff for running lint and formatting checks.
Also added to readme instruction on how to setup pre-commit check

Changed config to prefer double quotes for docstring as advised in PEP 257

Changes:

• Replace separate Black, Flynt, Flake8, and Ruff CI jobs with a single Ruff quality check job.
• Simplify scripts/pyformat so it uses Ruff only for formatting and linting.
• Keep pre-commit wired through scripts/pyformat -c, but rename the hook to Ruff Python Quality.
• Move formatter ownership from Black to Ruff in pyproject.toml.
• Remove replaced formatting/lint dependencies from requirements.txt.
• Update scripts/pyanalyze and README docs to reflect Ruff-based checks.

[ol-nata]

1. I'd prefer not to reformat existing migrations. They are historical artifacts, and formatting them adds a lot of noise with little practical benefit. It also makes reviews and git blame less useful.

2. I don’t think splitting commits by tool (ruff format / ruff check --fix) is useful for review or Git history.

   Each commit mixes multiple unrelated kinds of changes, which makes review and later debugging harder. I’d suggest splitting commits by intent instead, so each commit represents a single coherent change that can be reviewed, reverted, or bisected safely:

   • formatting-only changes (quote style ' → ", docstring quote changes, f-string quote normalization, import ordering, whitespace changes)
   • safe lint fixes (removal of unused imports like DeepHash, Meta, TestIterationResult, unused serializers, minor cleanups)
   • code simplifications (removal of else after return, class X(object) → class X, small expression simplifications)
   • potential logic-affecting changes (changes in conditions/loops/lambdas, variable replacements)

   This would make the history more atomic and significantly improve reviewability and git bisect usability.

[okt-limonikas]

1. I'd prefer not to reformat existing migrations. They are historical artifacts, and formatting them adds a lot of noise with little practical benefit. It also makes reviews and git blame less useful.

2. I don’t think splitting commits by tool (ruff format / ruff check --fix) is useful for review or Git history.
   Each commit mixes multiple unrelated kinds of changes, which makes review and later debugging harder. I’d suggest splitting commits by intent instead, so each commit represents a single coherent change that can be reviewed, reverted, or bisected safely:

   • formatting-only changes (quote style ' → ", docstring quote changes, f-string quote normalization, import ordering, whitespace changes)
   • safe lint fixes (removal of unused imports like DeepHash, Meta, TestIterationResult, unused serializers, minor cleanups)
   • code simplifications (removal of else after return, class X(object) → class X, small expression simplifications)
   • potential logic-affecting changes (changes in conditions/loops/lambdas, variable replacements)

   This would make the history more atomic and significantly improve reviewability and git bisect usability.

Should be done