BLI: introduce UString type for more efficient string handling

This adds a new `UString` ("unique string") type in `BLI_ustring.hh`. It is a
thin wrapper around `OpenImageIO::ustring`. OpenImageIO is already a required
dependency, so it's okay to rely on it being available here.

`UString` is just 8 byte large and can still convert to `StringRefNull` or
`const std::string &` in constant time.

See the in-depth code comment for more details of what a `UString` is. The tldr
is that it makes it very cheap to store and compare strings when the same
strings are reused often.

Additionally, this also adds a `_ustr` string literal operator which allows
creating ustrings very conveniently by writing `"my string"_ustr`. Other than
the similar `_us` operator in OpenImageIO, this one templated on the string and
can therefore efficiently cache the `UString` represenation of a string literal
instead of having to do a string lookup to make it unique every time. This
implementation also requires `FixedString` utility type which has been added in
`BLI_fixed_string.hh`.

Translation code has been updated to be able to detect string literals with a
`_ustr` suffix too.

----

For testing, I changed the panel name stored in `PanelDeclaration` from
`std::string` to `UString`. I intend to use this in more places after this
initial commit though. Having to add the `_ustr` suffix in many places is
slightly annoying but seems like the most efficient approach. The compiler
enforces this since there is no implicit conversion from string literals to
`UString` (it's not free).

Using `UString` for panel names (or pretty much all strings in node declarations
for that matter) is nice because these are fairly stable over an entire Blender
session. Currently, there are many `std::string`s stored in node declarations
which are large and are recreated every time a node declaration is build. Using
`UString`, especially with the `_ustr` prefix makes building the declaration
much cheaper because all the string operations are basically eliminated. Note
that many node declarations are not just build once but whenever properties
change because nodes can be dynamic.

The impact for just panel names is small (that's why I used it here), but I
expect even more benefits from using `UString` for descriptions (which are so
long that they require allocations) and especially socket identifiers which can
also make Geometry Nodes evaluation faster.

Pull Request: https://projects.blender.org/blender/blender/pulls/155211

scripts/modules/_bl_i18n_utils/settings.py

@@ -216,6 +216,7 @@ _str_base = (
             ".(?!(?P={_}2))"
         ")*.)"  # Don't forget the last char!
     "(?P={_}2)"  # And closing quote.
+    "(?:_ustr)?" # Optional trailing _ustr.
 )
 str_clean_re = _str_base.format(_="g", capt="P<clean>")
 _inbetween_str_re = (