[Portaudio] Improvements to CMake build system on Windows

[n***@appletonaudio.com]

We have two conflicting goals. One is to modernize the code base and
make life easier for skilled developers. So we want to encourage
everyone with an 8 year old SDK to upgrade to the latest tools.
The second goal to is make it easy for students, some of whom are
struggling with old computer systems, to use PortAudio to write audio
code. Their computers are sometimes very old and may not support the
more recent SDKs. If all the students have to do is install DirectX,
and that is easy, then I support this change.

Do these students really need the DirectSound host API? Worst case
they could just disable it. The MME host API is still there and it
works just as well as DirectSound in my experience.
If they absolutely need DirectSound, they can still get it from the
DirectX SDK, but they will need to provide the include and library
directories manually to CMake so that it can find it, instead of using
the DXSDK_DIR environment variable. That's not hard, but it's a
hurdle.
Also, if these students are using extremely old build systems, it
might make sense to tell them to stick to old versions of PortAudio
(such as pa_stable_v190600_20161030). Generally speaking, old versions
are more likely to work on old systems, since everything would be
"consistently old", so to speak.
Another alternative would be to distribute prebuilt PortAudio DLL
binaries and headers so that they don't have to struggle with the
PortAudio build system in the first place.
Or are you saying that these students want to make changes to PortAudio
itself?

Any objections?

Honestly I cannot make any guarantees about any of my patches building
on 8-year old systems. I don't have such a system to test, and I
definitely wouldn't want to spend the time to bring one up. If someone
has such a system, I would encourage them to test the patch themselves
and report back with a suggested fix.

I've reviewed the changes/bug-fix to the CMake support and provided Phil
is OK with the DirectSound modification I would be very happy for
Etienne to merge this in. I've up-voted it on Assembla.

Just to add my take on this discussion: I'm also of the opinion that
it's unreasonable to expect contributors to run testing on hardware that
is outdated/unobtainable. If we make the change and it breaks a
particular end-user's setup, we can add a workaround and document why it
exists in the build metadata. At present, there is no documentation
which specifies why odd things are way they are and it's reasonable to
look at it and think: this should be removed/fixed.