Divergence from Win32 RC: `\xFFFF` in the class name parameter of `CONTROL`s

[squeek502]

If the class name of a control is specified as a L-prefixed string literal and the first character is the escape sequence \xFFFF, then the value gets compiled to a number rather than a NUL-terminated string.

This compiles to NUL-terminated UTF-16:

1 DIALOGEX 1, 2, 3, 4 {
  CONTROL, "baz", 4, L"abc", 1, 2, 3, 4, 5
}

This compiles to FF FF 7A 00:

1 DIALOGEX 1, 2, 3, 4 {
  CONTROL, "baz", 4, L"\xFFFFzzzzzzzzz", 1, 2, 3, 4, 5
}

Currently, resinator writes the bottom example also as NUL-terminated UTF-16.

Two options:

• Match the WIn32 behavior
• Keep the current behavior of resinator, but emit a warning about the Win32 RC compiler's behavior when the situation is detected