There's a merged pull request on the void-packages repository

New package: hatch-1.2.1
https://github.com/void-linux/void-packages/pull/37514

Description:
<!-- Uncomment relevant sections and delete options which are not applicable -->

#### Testing the changes
- I tested the changes in this PR: **briefly**

<!--
#### New package
- This new package conforms to the [quality requirements](https://github.com/void-linux/void-packages/blob/master/Manual.md#quality-requirements): **YES**|**NO**
-->

<!-- Note: If the build is likely to take more than 2 hours, please add ci skip tag as described in
https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration
and test at least one native build and, if supported, at least one cross build.
Ignore this section if this PR is not skipping CI.
-->
<!--
#### Local build testing
- I built this PR locally for my native architecture, (ARCH-LIBC)
- I built this PR locally for these architectures (if supported. mark crossbuilds):
  - aarch64-musl
  - armv7l
  - armv6l-musl
-->

### Bikeshedding opportunities
 - ~~As they aren't just libraries, but also CLI tools, do hatch/hatchling need the `python3-` prefix? I personally don't like it, and would argue in favor of removing it.~~ Considering no one commented on this bit, I've decided to just get rid of.
 - ~~There's nearly no testing happening here, but that's due to the deps either requiring git checkouts with submodules, or themselves to be installed for testing. Any opinions on this? I'd prefer to have some amount of automatic testing here and not just a "JC has run this on his laptop once", considering that these are likely to be fairly central Python packages~~ there are a few tests failing now, but they are being run and there's a hundred times more tests that do work as intended. The ones failing where it's expecting to be running /usr/bin/python, but is actually running /usr/bin/python3 or similar things, which is fine IMO.
 - ~~Is a major update of python3-click something that might need additional testing? 29 of our packages depend on it, but on the other hand, it's *probably* fine, right?~~ Has been updated outside of this PR.
 
Fixes #37334