Create test that non-UTF-8 locales don't deadlock

From Qt 6 (current dev) we shall impose UTF-8 on the locale used by Qt applications.
The code that does this (except possibly on Windows) produces a qWarning() if the actual locale wasn't in UTF-8, which was observed to produce a deadlock in at least one app (which may have been flawed, but users write those, too) that exercised QQuickStyle::setStyle() before a QApplication was instantiated; this exercised code that needed the locale, triggering the code to impose UTF-8, before the infrastructure of qWarning() was in place. That lead to an attempt to set up that infrastructure, which tried to take a lock already held by the code that had lead to the UTF-8 override code, resulting in deadlock.

This shall be fixed (and relevant Coin config has been updated to prevent the problem triggering in the mean time), but we should aim to include a test that would catch it if it isn't as fixed as we imagine.
The original issue that addressed the deadlock was COIN-578, triggered by a failing integration that hung on macOS (which defaults to UTF-8 for user sessions, but not for every process).
It is likely the test that hung here will be fixed (to not use QQuickStyle::setStyle() so early), but the version of it before such a fix may be a good start-point for the RTA test to be written.
The aim of the test should be to fail gracefully or succeed, in either case alerting the user to the need to set a more modern locale.

Although the failure was only seen on macOS, we should test on other systems where possible, e.g. configuring the test system to use the raw C locale. Overtly specifying its encoding as ASCII may be worth doing, in so far as the test system supports doing so.