Please consider vendoring flatbencode to simplify dependency management

Hi! I'm working on [packaging torf for Debian](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101302) and ran into an issue with the `flatbencode` dependency To make a Python package available in Debian, all of its dependencies must also be packaged for Debian. When introducing a new package into Debian, maintainers evaluate whether the upstream project is actively maintained and well-supported, since each package becomes a long-term maintenance burden for the Debian community. This creates a problem with the `flatbencode` dependency. The library consists of a single file (https://github.com/acatton/flatbencode/blob/master/flatbencode.py) and hasn't been updated in over 10 years, with no signs of active maintenance. I doubt flatbencode would be accepted as a new Debian package in its current state, but packaging it separately just for torf seems excessive anyway, given it's a single-file library. Would you consider vendoring flatbencode.py directly into the torf source tree? Since it's a small, stable file implementing a format that's unlikely to change, and it's MIT licensed (compatible with GPL-3.0+), vendoring seems like a reasonable solution. This would allow me to package torf for Debian without requiring a separate flatbencode package. Alternatively, would you consider switching to an actively maintained bencode library, such as [fastbencode](https://pypi.org/project/fastbencode/), which is already packaged in Debian? I'd be happy to help with a PR if you're open to either approach. I really want to make torf available to Debian users! Thanks for considering this.