cmake: allow CURL_STATIC_CRT with UCRT VS2015+ builds

[vszakats]

After this patch, we're back to 8.12.1, but disallowing
CURL_STATIC_CRT=ON with shared curl exe built with VS2013 or older.
Because those may crash. A stable reprducer is with ENABLE_DEBUG=ON
and calling curl.exe -V.

You can pass the necessary CMake and MSVC linker options manually,
to get around this condition.

Shared build with static UCRT may be crashing too, depending on
conditions. Consult the documentation about limitations of static CRT:
https://learn.microsoft.com/cpp/c-runtime-library/crt-library-features

Follow-up to 049352d #16516
Follow-up to edfa537 #16456
Ref: #16394

[vszakats]

The crasher printf() is before stderr init, I wonder if there is any way
that it touches stderr internally somehow anyway?

Here's the reproducer PR and CI VS2017 job:
#16522
https://ci.appveyor.com/project/curlorg/curl/builds/51605732/job/12n581uytend97mx
it's a hung job due to the GUI popup.

OK:

• VS2017 NOT debug-enable is OK: https://ci.appveyor.com/project/curlorg/curl/builds/51605732/job/8581sqkem3irljjl
• identical VS2019 build.
• VS2022 are built either static or Release, but the first job is debug-enabled and OK.

Hang:

• CMake, VS2017, Debug, x64, OpenSSL 1.1.1, Shared, Build-only
• CMake, VS2017, Debug, ENABLE_DEBUG=ON, CURLDEBUG=OFF, x64, OpenSSL 1.1.1, Shared, Build-only
• CMake, VS2022, Debug, x64, OpenSSL, Shared, Build-only
  Ref: https://ci.appveyor.com/project/curlorg/curl/builds/51605952

So far it seems in crashes on these conditions:

• curl's printf() before stderr init. (CRT printf() OK: https://ci.appveyor.com/project/curlorg/curl/builds/51606047)
• --config Debug (or other Debug variants presumably) (meaning a Debug CRT)
• CURL_STATIC_CRT=ON
• ENABLE_DEBUG=ON (regardless of CURLDEBUG aka MemTrack)
• VS2017 or VS2022. (VS2019 seems fine)

It's very odd.

Seeing these it seems slighly more likely that curl's printf() might be touching stderr
in debug builds. Pure guessing based on the alignments above.