Purpose and Motivation

A new version of libsndfile (1.1.0) was released and I wanted to update our macOS and Windows builds.

This is a little more invasive than I'd like. I switched both macOS and Windows builds to use vcpkg to supply libsndfile.

• on macOS we were manually building libsndfile to facilitate custom (lower) deployment target; instead of updating all the sources by hand, I decided to switch to vcpkg, which allows us to build the library using the desired deployment target (and should be easier to maintain in the long run - updates of libsndfile in vcpkg will automatically be included in SC builds)
  • I had a hard time making shared libraries work and pass CMake's verify_app; i.e. libsndfile as shared library is fine, but its dependencies (libvorbis, flac etc) were confusing to CMake's verify mechanism (though seemed to work fine). In any case, I decided to create a custom vcpkg triplet, which builds only selected libraries as shared, and the rest as static. This creates a single libsndfile library with all dependencies built-in and passes verify_app
• on Windows we could wait for chocolatey to update the library... but I'm not sure when that would happen. Building with vcpkg seems fine here
  • I added a custom triplet for 32-bit release (no debug) build
  • libsndfile's dependecy mpg123 fails to build under mingw, so in that case we still use chocolatey's library
• in the process I made minor changes in CMake to facilitate finding libsndfile from vcpkg

I tested the legacy build on macOS 10.11 and it still seems to work, the server boots (I had to revert an XCode version change I originally introduced in this for it to keep working).

A basic test for this PR would be to download the build and make sure it starts and that the server boots, maybe read a soundfile too.

Types of changes

• New feature (not directly, but eventually we can take advantage of libsndfile's new features)

To-do list

• Code is tested
• All tests are passing
• Updated documentation
• This PR is ready for review