Switch build-backend from setuptools to hatchling

[BrianJKoopman]

Description

This PR switches the build system backend from setuptools to hatchling.

Since versioneer only supports setuptools based projects, we drop that as well, removing the vendored copy we were including. The closest functionality I could find to that was through hatch-vcs. This results in slightly different versions compared to versioneer, illustrated by this example:

versioneer: 0.11.2+7.ga1e7e91
hatch-vcs: 0.11.2.post1.dev7+ga1e7e91

In switching backends we entirely replace setup.py/setup.cfg with the more modern pyproject.toml.

Motivation and Context

When setuptools broke our builds (see #391) I wanted to explore modernizing our builds by migrating to a newer backend. There are many choices, but I settled on hatchling because some other SO projects (like nextline) use it, and it's the first tab in documentation in the Python Packaging User Guide, so seems inherently recommended.

How Has This Been Tested?

I have built the package, installed locally, and run the tests on this installation. I've also inspected the contents of the tarball compared to the latest version (v0.11.2) up on PyPI. I've dropped including the tests/ directory in the sdist. setuptools was only partially picking this up. I debated including tests/ and docs/ in the sdist, but have left them out at this time. Let me know if you feel we should include them.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Packaging change

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[BrianJKoopman]

Going ahead with this after discussion in the meeting today.