autotools: use unversioned real package.

[dragon-archer]

After previous PRs, now all packages in MSYS2-packages and MINGW-packges can be built with the latest autotools. This PR aimes to provide unversioned real package of automake and autoconf.

Previous versions and autotools-wrapper are kept in case any package requires a specific version of autotools. Considering Arch always use the latest autoconf and automake, I think old versions of autoconf and automake can be removed here or in the near future.

Note that ${MINGW_PACKAGE_PREFIX}-autotools also depends on autoconf-wrapper and automake-wrapper. Not sure we should update that in a transaction, or let autoconf and automake provides there wrapper (seemes strange, but may let pacman happier? Not sure whether there're any downsides of 2 packages providing each other.)

[dragon-archer]

Successfully did the update on my local machine. Seemes like pacman is clever enough for this.

[lazka]

How do you know it builds with the latest autoconf/automake? By default it uses the version the files were generated with, not the latest.

And what should we do on the next autoconf version that is incompatible?

[dragon-archer]

Arch, Debian, and Ubuntu all uses the latest autoconf with a few obsolete versions kept (namely 2.13 and 2.69). I think there's nothing special for us to keep so many versions.

Generally, I don't think the next autoconf version will be incompatiable to a large range of packages, and autoconf update very slowly (ususally 2 years or even longer). If some package do requires an older version, i.e. 2.69, then we can simply let it makedepends autoconf2.69 instead of autoconf

And, as of automake, Arch, Debian, and Ubuntu all only keep the latest version, so I think it should be safer to remove other versions.

[lazka]

Unlike those distros we autoreconf, they usually just call configure as is. Gentoo autoreconfs a lot also, which is why they developed the wrapper.

[dragon-archer]

We usually use autoreconf -fi (and opionally -v), which is more compatiable then simply autoreconf as all files generated from older autoconf will be regenerated.

And, if something do break, we can always specify a specific autoconf version for it.

After all, we cannot keep all autoconf versions for all the time. We don't even keep older GCC (GCC16 update DO break some packages, but it turns out that fixing this type of break is easy).