Adds support for various automake version, fix install on alpine Linux

[MrMarvin]

The current approach to bypass automake as a dependency (introduced with #118) is in fact limiting which versions of automake are supported. This reduces portability of this package, as different Linux distributions ship various versions, most of them newer than the one our current configuration is created for.

This is particularly problematic when installing httpuv on alpine Linux - very common in containerized environments. This PR fixes #280.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[anjafr]

Any chance of this being merged soon? We use Alpine Linux systems at work and this issue makes the setup quite a bit flaky - would really appreciate to see a solution! 🥳

[wch]

Unfortunately, I think it's likely that this PR will break httpuv on other (non-Alpine) platforms -- the logic that was removed by this PR was added for a specific reason. We'll have to find a method that we're sure works on all platforms.

[MrMarvin]

I'm unsure if bundling system specific configuration files from the package developers systems to all users systems is a good idea. For a package that's building from source anyway.
The current solution literally tricks autotools into believing it already ran recently, making it use the committed generated files instead of generating configuration on the fly. To my understand the initial issue #107 could have been solved by the user installing automake as a dependency.

While I agree that it would be great if users of the package would not need to have those build dependencies installed, I'd argue this is a use case for binary distribution packages. The source package should be as portable as possible. This means not requiring a certain version (or family of compatible versions) of automake. Additionally if we decide to move forward in this way, it should be at least clearly documented what systems are supported and a clear error message given to users in unsupported environments. What do you think, @wch?