frontend, libobs: Base work for localization and utf-8

[Dankirk]

Description

• Sets UTF-8 as active codepage for Windows in obs.manifest file.

  • This changes Windows APIs to use utf-8 for the A(nsi) functions instead of the language dependent ANSI codepage. The W(ide) functions are untouched and are still used by default since we use the UNICODE build flag. This also helps directing less encoding-aware 3rd party plugins and libraries towards a supported encoding.

  • Active codepage also encodes commandline arguments on Windows as utf-8, which allows for example ./obs64.exe --profile <name> to load profiles with special characters correctly.

• Change time formatting for logging to use ISO standard without localization to preserve logging format in different locales.

• Casts ctype function parameters from char to unsigned char to prevent non-ascii input from crashing them. Functions expect parameters to be in 0-255 range, which char using utf-8 casted to int might not be (signed char range is -128 to 127)

Motivation and Context

This is based on discussion PR #12624 and split from the main issue there.
This serves as ground work for enabling localization and handling utf-8 data with C APIs

How Has This Been Tested?

Tested active code page effect by naming a scene with some Japanese characters, selecting another scene so it's not opened by default on restart and then restarting the app with command line

./obs64.exe --scene <japanese characters>

This wasn't working in current version on Windows.

Types of changes

• New feature (non-breaking change which adds functionality)
• Tweak (non-breaking change to improve existing functionality)

• Breaking change (fix or feature that would cause existing functionality to change)
  • 3rd party plugins etc, that have been using -A versions of Windows API have to expect them to give out/take in strings encoded in utf-8 instead of default ANSI code page.
    • It's still not broken if:
      • It's in ASCII range
      • If they needed wchar of it they used MultiByteToWideChar() with CP_ACP flag (using other flag may have been broken, but if it was CP_UTF8 it is now fixed)
      • Otherwise if the text was used as input to an obs api directly, it's now coincidentally in correct encoding.
    • It is breaking if:
      • Their source file is in their default ansi non-utf8 encoding, their build options reflected that, they have non-ascii hardcoded strings there and they used them for a Windows -A api, but not for an obs api
      • They saved the string, it was non-ascii, and they try to use it now for Windows A function again.
    • Otherwise it was probably already broken

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[Dankirk]

If the manifest utf-8 declaration is deemed too risky (detailed this in "breaking change" section of the description), we could do the commandline argument parsing with GetCommandLineW() or introducing wmain() for Windows and following with os_wcs_to_utf8().

[PatTheMav]

@RytoEX Was split off from the original PR. Changes to the time format (using fixed %F and %T) seem indeed more correct to me, and casting the character values to unsigned char to fit the expectations of the underlying functions is also correct to avoid triggering undefined behaviour.

The UTF-8 codepage change allows OBS' existing commandline argument parsing code to correctly handle arguments using non-ASCII characters on Windows, but will affect any call to an ANSI Windows API function (and indeed any call to a C library call) in turn.

[RytoEX]

Generally, I prefer the explicitness of %Y-%m-%d over the brevity of %F because I can immediately recognize the former while I have to look up the latter.

@PatTheMav Aside from the breaking items mentioned, is there anything else this would break?