feat: native windows provider

[Kneemund]

This PR adds a provider for the native spellchecking added in Windows 8. Deleting words from the session (optionally) requires at least Windows 10. Closes #52.

I spent quite some time fighting the build system. The squashed changes seem idiomatic to me. I'd appreciate some feedback on that ;)

I've also made all providers use their own <NAME>_LIBS variable instead of appending to the global LIBS. I think that was intended at some point, but never actually done, since most of these variables were already in-place in the provider Makefile.

CI

• Linux failed because apt-get update wasn't being ran prior to installing packages. This PR fixes that (see 6eb467f), even though it's unrelated.
• Windows failed because the enchant CLI incorrectly assumed that all FileStream inputs are using the system locale encoding (which is the ANSI code-page on Windows, and UTF-8 on other systems). Now, the CLI first checks if the input is already valid UTF-8 before attempting that conversion (see ec553de).
  (I doubt that this conversion is necessary, but I guess we can keep it in case anyone depends on it.)
• MacOS (still) fails because AppleSpell doesn't think that "teh" is misspelled. I'm not sure why that only happens during make distcheck (and not make check). Either way, that's unrelated to this PR.

Licensing

I'm by no means an expert at licenses, but here is the way that I see things. This should definitely be double-checked by someone other than me.

The new provider uses the bcp47 module from gnulib to convert between BCP47 language tags (which Windows uses) and XPG/POSIX language tags (which all other providers use). This module is licensed under LGPLv3+. The source code of the provider is licensed under MIT. That makes the whole provider derived work and thus also LGPLv3+.

I think that enchant itself stays LGPLv2+, since the provider is loaded dynamically and not at all a core component.

In the process, I had to loosen the LGPL restriction of gnulib_tool (see 4f9ac6b) so that it can include any LGPL licensed modules, not just LGPLv2 licensed ones. That means that we have to be more careful about the modules we use in the future. I don't know if we can somehow limit this to just the new provider. We would probably need an entirely separate build step.

TODOs

• Use a better name and description for the provider. win8 sounds like it only works on Windows 8. Suggestions would be very welcome.
• Fix the failing test on Windows.

[rrthomas]

This is amazing to have, many thanks! I must apologise that you've caught me at a moment where I'm unable to be likely to look at it in a matter of days, and possibly not weeks, so do ping me if you don't hear for a while, but rest assured it is something I really want to land.

Thanks in particular for taking care with the build system and checking the situation with the tests and CI.