Merge remote-tracking branch 'origin/blender-v2.92-release'

Windows: Fix wchar_t truncation

BLI_strncpy_wchar_from_utf8 made the assumption that
wchar_t is UTF-32 bit regardless of environment, while
this holds true on both mac and linux, on windows
wchar_t is actually actually UTF-16.

This resulted in the upper 16 bits being dropped from
from some string conversions and prevented blender
from starting when installed in a path with unicode
code-points over 0xffff.

There was also a fair bit of code duplication between
BLI_strncpy_wchar_from_utf8 and BLI_str_utf8_as_unicode_and_size

this change essentially removes all logic from
BLI_strncpy_wchar_from_utf8 and calls the right function
for the right environment.

Reviewed By: brecht , Robert Guetzkow

Differential Revision: https://developer.blender.org/D9822

Windows: Remove zero terminator from stack trace

Important lesson to be learned here, leaving comments
is great and in the moment, they usually make sense.

Many months later they may not quite make as much sense
any more and time will have to be spend to figure out
what was meant, all of this would have been averted with a
better comment.

The zero terminator in this case, I can find no evidence
of it being used or relied on at any point. It does however
break GTests's `EXPECT_EXIT` macro that stops looking in
the output as soon as it sees the zts and doesn't end up
looking at the actual assert text being thrown. Which in
turn makes the`fcurve_active_keyframe`test fail when run
in debug mode on windows.

Merge remote-tracking branch 'origin/blender-v2.92-release'

Fix: Build error with MSVC 2017

BKE_cryptomatte_extract_layer_name was using std::isdigit
without including <cctype> somehow only MSVC 2017 had a
problem with that.

Clean-up: Fix build warning with MSVC

Callback function was using int while update_render_passes_cb_t was
using eNodeSocketDatatype leading to a build warning about different
argument types with MSVC.

Fix: Python warning in windows debug builds

When doing a debug build on windows, blender will
start with the following warning:

"Unable to find the python binary, the multiprocessing
module may not be functional!"

The root cause for this issue is: for a debug build
the python binary is called python_d.exe rather than
just python.exe

This change fixes BKE_appdir_program_python_search
to look for the _d suffix for debug builds on windows

Differential Revision: https://developer.blender.org/D9775

Reviewed by: Campbell Barton

Fix: Fix potential memory leak in BLI_getenv

Issue introduced in rB87b19b3aba0c and unlikely to occur
but no reason not to have correct code.

Fix: BLI_getenv returns ascii not UTF8 on windows

BLI_getenv has always incorrectly returned ascii rather
than UTF-8. This change corrects this behaviour.

This resolves issues when the `BLENDER_USER_CONFIG`
environment variable contains a path with Unicode characters
on windows as reported in T74510 (but unlikely the root
cause for the issue at hand there)

Differential Revision: https://developer.blender.org/D9831

Reviewed by: brecht

MSVC: Enable clang-tidy analyser

This enables the use of clang-tidy in the VS IDE.

To use it:

1 - Enable WITH_CLANG_TIDY in your cmake configuration
2 - From the Analyse pull down menu select Run Code Analysis on...

The analyser is currently not enabled by default on build
given it is quite slow and there are quite a few problems
it reports that we still need to deal with.