[PREVIEW] New SoundSource API

This pull request is only a preview that shows work in progress. Please note, that I will rebase the corresponding branch frequently on mixxxdj:master!

The CachingReader(Worker), AnalyzerQueue and ChromaPrinter are already using the new AudioSource API. The old SoundSource API has been removed from the public interface of SoundSource. A generic (although inefficient) bridge implementation of readFrameSample() is provided by the SoundSource base class that invokes the legacy read() method. The visibility of read() has been reduced to "protected" to avoid any future usage.

Decoders that are already implementing the new AudioSource API, even if there still might be a lot of work remaining to improve the existing code base:
- SoundSourceFLAC (+ optimizations)
- SoundSourceMP3
- SoundSourceM4A

All other decoders are more or less working through the bridge implementation of readFrames() in the SoundSource base class. I must admit, that I did not test their functionality, but at least the code should compile without errors:
- SoundSourceOggVorbis
- SoundSourceOpus
- SoundSourceFFmpeg
- SoundSourceSndFile
- SoundSourceWV
- SoundSourceModPlug
This ordering also reflects which SoundSources should be migrated next. If you see a different ordering, please comment.

The following decoders might be broken, because I'm currenly not able to compile and test the code:
- SoundSourceCoreAudio
- SoundSourceMediaFoundation 

Btw, using C++11 features would be really helpful! I've seen some changes in this direction in another pull request ;)
Agreed :) The function is only used at 3 places in the so code, so a longer name doesn't matter here.

This is also the reason why I provided a special-case version readStereoSamples() or readStereoSamplesInterleaved() that explicitly tries to read stereo frames from mono or multi-channel sources. This is what the following processing stages implcitly expect to read. Before this functionality was more or less buried deeply in the individual implementations of the decoders. Now it has been made explicit, still giving decoders the chance to optimize for this common use case.

I found various code that made implicit assumptions that were hardly documented with lots of "magic numbers" involved. I prefer to use the programming language itsel for documentation purposes, because code does not lie and the compiler is ruthless ;) I found many comments or commented out code that simply did not apply anymore or did not match the surrounding code.