This replaces all the logic of using the Windows registry to obtain the font path by using DirectWrite. The goal is simply to improve the quality of the code. This doesn't change any functionality

Uniscribe was only used for the FontCollector. Since we now use DirectWrite, we don't need it anymore.

…raise

On Windows, the initialization of the FontCollector can raise an exception

…can throw

… occur

…RITE_3

…se to std::wstring

…ect fake_italic/fake_bold

See this comment: arch1t3cht#107 (comment)

…correctly verify if font has character(s)

With the Visual Studio 2019 toolchain on Windows 7, it installs the Windows 10 SDK by default. Because of this, ``HAVE_DWRITE_3`` is true, so the ``QueryInterface`` always fails. Now, if the ``QueryInterface`` fails, we try to verify if the font has characters with a Windows Vista SP2 compatible code.

…pace AND truncated facename

Problem 1:
Previously, if a user wrote "\fn   ", it would return the font Arial, which is not what we want. This is because when we request EnumFontFamiliesEx with whitespace or an empty lfFaceName, it will enumerate all the installed fonts.

Solution 1:
To resolve this issue, let's implement a solution similar to libass to determine if the selected facename exists: https://github.com/libass/libass/blob/649a7c2e1fc6f4188ea1a89968560715800b883d/libass/ass_directwrite.c#L737-L747

Problem 2:
GDI truncates font names to 31 characters. See: libass/libass#459
However, since I changed the method to determine if a facename exists, I ensured that we still support this "feature".

To test this, I used the font in: libass/libass#710

…ion of std::wstring over WCHAR