Revert "wget: Added a patch to fix build with Gettext 0.18"

This reverts commit 4c1c93c4194ef4d845d7397c04a31ab54ca6219a.

This is not a fix. It is not even a workaround, since it breaks the
build on the two systems I tried it on.

The purpose of the version number is to check whether "po.m4" and
"po/Makefile.in.in" originate from the same gettext release. Just
increasing the version number without replacing the rest of the file
is asking for problems. Also, updating "po/Makefile.in.in" without
updating "m4/po.m4" will ensure they are out of sync. The only way
this can build at all is if the wrong "po.m4" is picked up. So we
have to fix that instead.
Revert "wget: Added a patch to allow skipping generation of documentation"

This reverts commit 7edcf8556ce14ed7a633cd1b17bf5f57f0b654d8.

The commit was actually fine in itself, but the autoreconfigure
triggers a pre-existing problem that I don't have a fix for.

That problem is that some packages include the m4 files they need,
while other packages rely on systemwide installed m4 files. In the
case of wget, using systemwide installed files causes a version
conflict between po.m4 installed by gettext and po/Makefile.in.in
from wget.

Eliminating systemwide installed files from the aclocal search path
fixes the wget build, but breaks util-linux and shared-mime-info.
I also tried to play with search path orders, but couldn't get a single
configuration that worked for all of these three packages. Plus the
automake manual warns that changes to the default search paths are
being considered for a future release.

A possible solution would be to have a per-package setting whether to
use systemwide m4 files or not, but implementing a mechanism for that
is a task in itself. Right now, reverting this commit is the lesser
evil.