Inspite of claims to the contrary in fontconfig 2.11 changes log,
FontConfig is really not thread-safe, since it uses atomic pointers
instead of proper reference counting. Consequently, LibVLC cannot
safely call FcFini() - it could crash another thread using FontConfig
concurrently.

Using our own configuration has the benefit of not leaking related
memory allocations, though it means that the LibVLC text renderer
cannot share the configuration with other components in the same
process.

Note that there are still leaks within FontConfig. Specifically, the
cache and the language/program default values are not freed, since that
would require FcFini(). If you care in your application, call FcFini()
after you have terminated all LibVLC instances.

Refs #16023.