Packaging: Convert from setuptools to hatch

[dairiki]

I started working on packaging Lektor using hatch a few weeks ago.

The use of hatch allows for:

• Building the frontend javascript and css as part of the PEP517 build process using a build hook. In addition to simplifying the distribution building process by eliminating the make build-js step, this allows Lektor to be installed directly from a git repo.
• Management of development (and, potentially, test) virtual environments.

Issue(s) Resolved

Fixes #1081
Fixes #1057

Related Issues / Links

Description of Changes

• Wrote at least one-line docstrings (for any new functions)
• Added unit test(s) covering the changes (if testable)

• Link to corresponding documentation pull request for getlektor.com

(This work probably needs a bit of freshening. I'm creating this PR now since it relates to the newly created #1081.)

All or most of our tox tests could probably be converted to hatch scripts. At present, however, hatch does not support running scripts in parallel (e.g. there is no equivalent of tox -p) so running the full set of tests via hatch is painfully slow.

[frostming]

Keep it simple by using build?

[frostming]

It seems tox.ini isn't needed anymore.

[dairiki]

The reason I hesitate to get rid of tox is that hatch currently doesn't have any equivalent of tox -p — that is, it doesn't yet have the ability to run the various test environments in parallel (though, reportedly, that feature is planned). For the CI tests, it doesn't matter, but it does matter for the dev running the tests on their workstation.
And if we're going to keep the tox tests for that, I figure we should use them in CI.

[dairiki]

Closing in favor of #1112, which includes just the hatchling PEP 512 builder bits from this PR.

I don't think that using hatch to manage test and dev environments buys us much.

Our test requirements are complex enough that I think it's better we stick with tox for that.

For building distributions, however, hatchling is a flexible PEP-621build backend that is customizable enough that we can hook the esbuild-ing of our backend code into the PEP-512 build process, which is a big win.