adding pyptoject.toml and initial code quality workflows

[davidslusser]

Pull Request

Description:
Adding pyptoject.toml and initial code quality workflows. I strongly recommend using the toml file for tooling parameters to keep configuration consolidated and the root of the repo clean. I added workflows for bandit, black, and ruff (I think we all agree on these). There are many more we can add, but I'll let others take a stab at some before adding more.

Related Issues:

• closes Determine code styling tools #12

Checklist:

• All tests pass.
• Code follows the project's coding standards.
• Documentation has been updated.

[joeriddles]

I think the pyproject.toml file may have been missed in the commit

[davidslusser]

I think the pyproject.toml file may have been missed in the commit

actually, I missed multiple files somehow, doh! @joeriddles updated in the latest commit.

[joeriddles]

Noice! Should we just use ruff as both a linter and formatter and drop black altogether?

https://docs.astral.sh/ruff/formatter/

As such, the formatter is designed as a drop-in replacement for Black, but with an excessive focus on performance and direct integration with Ruff. Given Black's popularity within the Python ecosystem, targeting Black compatibility ensures that formatter adoption is minimally disruptive for the vast majority of projects.

[davidslusser]

Noice! Should we just use ruff as both a linter and formatter and drop black altogether?

https://docs.astral.sh/ruff/formatter/

As such, the formatter is designed as a drop-in replacement for Black, but with an excessive focus on performance and direct integration with Ruff. Given Black's popularity within the Python ecosystem, targeting Black compatibility ensures that formatter adoption is minimally disruptive for the vast majority of projects.

Noice! Should we just use ruff as both a linter and formatter and drop black altogether?

https://docs.astral.sh/ruff/formatter/

As such, the formatter is designed as a drop-in replacement for Black, but with an excessive focus on performance and direct integration with Ruff. Given Black's popularity within the Python ecosystem, targeting Black compatibility ensures that formatter adoption is minimally disruptive for the vast majority of projects.

I'm open to that. I'll remove it for now, can easily re-add if ppl want more quality tools.