Windows clang-cl build

[JoergAtGithub]

This is an experimental build with the clang-cl compiler that comes with VisualStudio 2019.
clang-cl is a clang compiler variant, with MSVC compatible command line interface.

The CI build fails due to a header of protobuf, which is part of the Windows buildenv. I could fix this locally by applying: protocolbuffers/protobuf@1d2e8d9

My local build succeed, passed all tests and works flawless. But it feels slower than the MSVC build - I expected the opposite after the auto-vectoization results from @daschuer in #4861

[daschuer]

It would be interesting how a mingw gcc build will perform.
We may also consider to make sample.cpp a library and compile only this with a different compiler.

[JoergAtGithub]

Mingw is wormhole of problems, you would need to change the code at numerous places. Once I spend hours on a simple command line programm, due to differences in the implementation in the C standard function scanf.
For Mixxx you would need to compile the whole buildenv with Mingw first, because it's not ABI compatible to the other compilers. Mingw also force you, to use their own debugger, profiler etc. due to ABI incompatibilty.

Clang-cl is just a drop in for MSVC - only the compiler itself is changed and creates ABI compatible binaries, PDB files etc.

[github-actions]

This PR is marked as stale because it has been open 90 days with no activity.

[JoergAtGithub]

I intend to delete the GitHub build action before merging.
Only the changes in CMakelists.txt and the fixes of build error/warning should be merged.

[Swiftb0y]

Anything left to do here?

[daschuer]

After merging this, we will have two windows build for every PR, a waste of energy if we will not use it, do we?
Can we disable it before merging and only enable it when we want to check certain things?

[JoergAtGithub]

Yes, the CI build was only for testing. I will remove it.

[Swiftb0y]

waiting for ci. thank you