Include autotools setup to ease downstream packaging/installation

[alerque]

First of all, seeing the justfile here as a job runner for developer tooling made me happy!

I realize this is a somewhat unconventional ask in the Rust ecosystem, but I would like to propose including GNU AutoTools tooling in this project. If this project would be willing to accept it, I have all the necessary bits worked out already for other projects and could pretty easily contribute it here.

Pros:

• No existing usage such as using cargo install directly to get a binary would change.
• Packaging for downstream distros would be easier and more normalized. Building Rust binaries is pretty easy by themselves, but when a project comes with other support files it gets a lot harder and distros end up adhoc-ing their way through. Many distros end up without all the possible files.
• Clap can easily be updated to provide shell completions and a man page matching the CLI usage. Getting these generated and installed these to the right locations is not something plain Cargo handles well, but almost every distro out there has built in support for autotools builds that do this right out of the box.
• Notable for this project because of the conflicting project of the same name autotools has support for building and installing binaries under alternate names, either with a prefix, suffix, or name transformation. This tooling is standardized and distro packagers know how to use it, so for example if they have a tera binary from the other project they could easily configure this one to install as teracli (./configure --program-suffix=cli). This would be corrected for in not only the binary name but the completion files and man page as well.

Cons:

• AutoTools is a bit arcane and can be obtuse, especially if you don't have a gray beard and haven't been hacking on Unix for decades. This would be mitigated by the fact that I have done this before and can contribute the whole thing and, once setup, it doesn't require much.
• The release process will be a little different that your other projects. How to handle versions can be adapted to whatever workflow is desired, but once a release is cut the best end user experience will be with a released source tarball (made with make dist) rather than just a Git generated archive. This will need to be generated and attached to releases for the best experience (of course that can be automated too).

As an example you can check out my git-warp-time project with is tooled up this way. You can build the binary or install with cargo build and cargo install like any Rust project, but if you download a source release or clone the repo and use ./configure && make && make install you get all the goodies like shell completions and the man page taken care of.