use `pre-commit` for git hooks

[SauravMaheshkar]

As the project moves forwards and adapts to use more static code analysis tools such as ruff(#18) and mypy(#17) it might be suitable to achieve parity between CI and dev by running same/similar workflows.

pre-commit is one such tool that would make that process much easier and enforce that the developers follow coding conventions even before it reaches CI.

A very simple config file could look like:

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: end-of-file-fixer
      - id: trailing-whitespace
      - id: check-yaml
      - id: check-toml
      - id: check-merge-conflict
      - id: requirements-txt-fixer
      - id: detect-private-key
  - repo: https://github.com/psf/black
    rev: 24.4.2
    hooks:
      - id: black
  - repo: https://github.com/pre-commit/mirrors-mypy
    rev: v1.10.0
    hooks:
      - id: mypy
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.4.4
    hooks:
      - id: ruff
  - repo: https://github.com/python-poetry/poetry
    rev: 1.8.3
    hooks:
    -   id: poetry-check
    -   id: poetry-lock
    -   id: poetry-export

[suzanneEmbury]

This is a great suggestion, thanks @SauravMaheshkar .

Maybe when we have mypy in place, you could submit a PR that starts to put some of this in place? I think I'd like to take a slow and steady route that gets us used to using the pre-commit hooks one tool at a time - especially while robota-core is being used by the UoM Open Source Software Club. If you had time at some point to submit a PR that picks one of the tools you've suggested here for us to get started with, that would be great. We can then look at gradually adding more in.

We probably need to improve our developer docs as well as we do that, so that we keep the barrier to contributing low and manageable. What do you think?