Move to pyproject.toml and cleanup non-source files

[nhairs]

Fixes #56, #49.

In addition to moving to pyproject.toml format, I've made a few other fairly significant updates:

• Add autogenerated CONTRIBUTORS from the git history, removed the AUTHORS file, and updated LICENSE to reference the contributors file since under the MIT Licence each contributor still maintains copyright over the code they added.
• Add more classifiers, specifically the Python versions and Typed. Changed the Development Status to Production/Stable since that probably more accurately represents that status.
• Added some badges to the README.md.
  • If you want to preview changes you can use a tool like grip
• Removed tox.ini, updated python-requires>=3.8, added 3.12 to CI
• Moved to f-strings (removed many "x".format(...))
• Applied black formatter
• Applied MyPy type checker
• Narrowed the type on Fingerprint.get_fingerprint - now only accepts BinaryIO.
  • I would be surprised if any program worked with StringIO files.
• removed six
• added static test files
• added .gitattributes
• lots of minor changes while on wild goose change to fix failing tests.

Test Plan

• Check tests still pass
• Validate pyproject.toml against validate-pyproject
• Check README.md using grip
• Check project builds

Questions / Discussion / Misc

• We may want to add a PR template to remind contributors to add their name if they haven't already.

Note

I strongly recommend this is merged using a squash commit (opposed to a merge or rebase - the commit history here is pretty garbage).

[nhairs]

@Acconut - I should add,

a. it /might/ be better now that we know cause of the broken Windows tests that we scrap this particular PR because there's a lot of potentially breaking changes (due to specifying / narrowing types for instance) and instead we could do a bunch of smaller changes b. If we're making breaking changes - do we lean into it and start a 2.0.0.dev branch for other changes we may want before releasing it?

[Acconut]

I haven't look thoroughly at this PR yet because it's a lot of changes, but I can answer the two recent questions.

it /might/ be better now that we know cause of the broken Windows tests that we scrap this particular PR because there's a lot of potentially breaking changes (due to specifying / narrowing types for instance) and instead we could do a bunch of smaller changes

I agree. It would make sense to fix the Windows tests in a separate PR and see how many of the improvements we can pursue in individual PRs before breaking backwards compatibility. All the other changes can then be done afterwards for a v2.

If we're making breaking changes - do we lean into it and start a 2.0.0.dev branch for other changes we may want before releasing it?

Yes, breaking changes will require a v2 release as we follow SemVer for all of our software :) If there are additional breaking changes, now will be a good time to make them. However, I don't know any changes out of my head that we had planned.

[nhairs]

In that case, probably don't worry about reviewing this PR, I'll break it up into a few (or more).

May not be for a little while though - depends on what I'm working on.

[Acconut]

Thank you very much for your help, @nhairs! I cherry picked the test fixes in https://github.com/tus/tus-py-client/pull/91, so we now have green CI in main again.