meson: simplify iconv/intl lookups using Meson's builtin dependency lookup

iconv/intl are complicated to look up. That complexity now resides in Meson, since 0.60.0/0.59.0 respectively, via dependency('XXX') lookup, so use that instead where possible.

No effort is made to support the old option for which type of iconv to use. It was a false choice, because if only one was available, then that's the only one you can use, and if both are available, the external iconv shadows the builtin one and renders the builtin one unusable, so there is still only one you can use.

For intl:

The Meson lookup doesn't include all the checks here, but likewise this meson.build doesn't include all the checks in Meson. Particularly, the following are different:

• Meson accurately detects support built into libc, even if that conflicts with an external library version (which should be detected as broken and thus not-found, but glib does not do so).

  The problem here is that depending on which libintl.h header is first in the search path, the *gettext symbols may be the libc ABI, or they may be renamed to libintl_*gettext, then additionally take over the *gettext names via a macro, in order to invoke the external library version even on systems where there is a libc builtin. This means that checking for cc.has_function() correctly reports that there is such a function in libc, but that unfortunately does not mean it is usable, because source code referencing ngettext etc. will expect to be linked to libintl_ngettext.

• glib checks whether the found intl requires pthread, rather than simply trusting the result of cc.find_library() for the external library case.

The logic is still a bit hairy, and eventually more of the logic could be moved into Meson. But it's better than before.

This MR does a bit of cleanup (in particular, iconv becomes super easy), and for both iconv/intl results in more accurate detection of a usable provider in situations where there are multiple providers, but only one works. This is the case on musl, which has builtins for both but users may prefer the GNU implementations, and also on e.g. the BSDs, which include POSIX iconv but also have GNU libiconv ports in case you want the more robust (particularly unicode) handling.