Support for Visual Studio in TF-PSA-Crypto 1.x and Mbed TLS 4.x

[gilles-peskine-arm]

The goal of this issue is to decide what level of support we offer for Visual Studio in TF-PSA-Crypto 1.x and Mbed TLS 4.x.

For reference, in Mbed TLS 3.6, we run the following CI jobs on Windows (not mentioned: target platforms and release/debug):

Description	Compiler	Build engine	Build script	CI script	Testing
win32-mingw	MinGW gcc	CMake + make	CMakeLists.txt	win32_mingw_test_bat²	unit tests + selftest
win32_msvc15_{32,64}¹	MSVC	CMake + MSBuild	CMakeLists.txt	win32_msvc*_test_bat²	selftest
Windows-mingw	MinGW gcc	make	Makefile	windows_testing.py	unit tests + selftest
Windows-2017-*-shipped*¹	MSVC	MSBuild	mbedTLS.sln	windows_testing.py	selftest
Windows-2017-*-cmake*¹	MSVC	CMake + MSBuild	CMakeLists.txt	windows_testing.py	unit tests + selftest

¹ Before https://github.com/Mbed-TLS/mbedtls-test/pull/203, we had different versions of Visual Studio: msvc15 (VS2017) was msvc12 (VS2013), PR jobs used VS2017 instead of VS2013, and release jobs used both VS2017 and VS2013.
² Defined in scripts.groovy.

In TF-PSA-Crypto, we intend to only support CMake as the build system. In particular, CMakeLists.txt is the only build script. Presumably Mbed TLS will follow suit (although at the time of writing it is still able to build TF-PSA-Crypto based on Makefile or mbedTLS.sln).

Thus, presumably, we will reduce the set of CI jobs as follows:

• MinGW testing: only via win32-mingw, no more using make from windows_testing.py. (We also do MinGW builds on Linux, where we can't test.)
• No more builds using MSBuild based on the shipped Visual Studio solution.
• MSVC builds using the win32_msvc* ad hoc scripts and using windows_testing.py “cmake” builds. We may want to simplify those, but that is orthogonal to drop of supported platforms, and tracked at https://github.com/Mbed-TLS/mbedtls-test/issues/26.

[irwir]

In TF-PSA-Crypto, we intend to only support CMake as the build system. In particular, CMakeLists.txt is the only build script. Presumably Mbed TLS will follow suit

It appears that CMake-generated files cannot properly replace standard Visual Studio projects. VS tries to use relative paths; such solutions and projects easily could be moved or copied to other locations (for tests, experiments). CMake inserts absolute paths and this seems incurable - as I read, relative paths created many issues. The releases currently have decent project and solution files generated with Perl script; hopefully this could be kept. Also, CMake is fully optional when working in VS IDE.