Cmake Support for MSVC builds.

[peterino2]

!! Not ready for merging yet.

I'd like to put forward a proposal to provide support for MSVC native builds on more modern versions of windows.

Providing more seamless support for MSVC should greatly improve the adoption story for the library, and make it easier to use from other languages (nim, rust, zig etc..) as it reduces the need for a cross compiling environment. Several issues have pointed this out such as #255

I Intend to provide a msvc compatible build leveraging cmake as the build generator. I've started some initial work on a PR here. as a proof of concept.

On windows you can now just

mkdir build && cd build; 
cmake ../ && start libsoundio.sln

And build through visual studio. (tested so far with vs 2022) No further dependencies are needed to use the WASAPI. It seems there has been some MSVC Support already from looking through the CMakeLists.txt.

Three issues need to be addressed in order to provide this support, and I'd like to hear thoughts.

1. msvc hilariously still doesn't support typeof and its' ilk of functions making an implementation of stdatomic.h not possible.
2. unistd.h is not available on msvc platforms
3. warnings and general build ecosystem stuff need to pass in MSVC builds.

1. an implementation of stdatomic.h not possible.

To remedy the lack of stdatomic.h I propose to leverage MSVC compiler intrinsics to implement the functions needed by the library and its' tests. this does result in an change in the atomics.h api. all SOUNDIO_ATOMIC_XXX functions now need to reference the target type of atomic they are operating on.

This is similar to the approach used by https://github.com/mintomic/mintomic (and its' replacement; turf) to achieve cross platform atomic implementation in C.

2. unistd.h is not available on msvc platforms

to this end unistd wont be used on the MSVC builds the only thing that was needed was sleep this is easily replaced by the windows.h 's Sleep function.

3. Passing all warnings in MSVC

This one sounds like a nice to have, and I'm still working on it.

But for a lot of warnings especially regarding Windows' static analyzer we may not be able to get all of them. In particular, ones where microsoft reaaly want you to decorate pointers with compiler specific attributes.

Some warnings I'm trying to fix pedantically:

1. inserting explicit casts where warned about
2. removing shadowed variables
3. (void) to mark unused variables.
4. proper declspec export macros for windows builds

Continuing on.

Let me know if this is a good direction for the library and I should commit to testing this far more rigorously, or if this should stay in a seperate fork.