Allow finer granularity for precompiled lib paths in JUCE modules

[TheSlowGrowth]

Use case: A JUCE Module contains precompiled static libraries. It is included in a JUCE project that gets built on different IDE / compiler versions from the same source code.

Problem: On Windows it is possible to have precompiled libraries for different versions of Visual Studio as well as Debug and Release versions in the JUCE module (simply because all these properties appear in the library search path inside the module - according to the JUCE Module Format). On all other platforms, there is basically just one path - making it impossible to work with multiple versions of XCode and forcing to link against release versions of the libraries even in debug builds.

Proposed solution: Maybe it would be possible to follow some logic like this (example for OSX):

libSearchPath = "${moduleDir}/libs/${XCodeVersion}/${arch}/${debug/release}/";
if not exists(libSearchPath)
   libSearchPath = "${moduleDir}/libs/${arch}";

This would stay compatible to the JUCE Module Format but also allow to work with multiple XCode versions as well as debug/release builds of the precompiled libraries.

Random thoughts: I'm wondering why the JUCE Module Format even makes a difference between Windows and the other platforms. My best bet is that for Visual Studio, there are different exporters in Projucer, so the desired version is known right away. However, there is only one XCode exporter, making it much harder to determine which version of XCode will actually be used to open the generated project file. It probaby isn't possible to embed a "polymorphic" library search path in the XCode project file that leaves the actual path to be resolved by XCode when it actually opens the file, so maybe that's why we have only one single path for the precompiled libraries. With CMake, this limitation is overcome because CMake knows what version of Xcode is installed.

[McMartin]

Requires #517 to be resolved first.