Pluginval as dependency

[sudara]

Closes #137

This improves support for pluginval as a CMake sub-project in a JUCE project.

After this PR, all one needs to do is add_subdirectory ("modules/pluginval") to a plugin project's CMakeLists.txt.

• Moves the JUCE dependency from a submodule to CPM
• Only adds JUCE when pluginval is the top level CMake project
• Only sets deployment target and generates docs when top level
• Removes PLUGINVAL_FETCH_JUCE option (no longer needed, superseded by not being top level)
• Adds documentation for "pluginval as a dependency"
• Adds some conditionals around 8.0.11 deprecations to allow earlier versions of JUCE.
• Add a test for pluginval as a dependency, testing plugins running both JUCE 8.0.3 and 8.0.11

To review, the benefits are:

• Full call stack. Right now when debugging via pluginval, one only gets the exact line of code in my project vs. the full stacktrace. See Make "pluginval as a dependency" a 1st class citizen #137 for an example.
• Less friction to start pluginval. Build the target from within the IDE and pluginval runs against the project. No need to open another project, pull changes, build, etc.
• Easy ability to set breakpoints in the main project
• I could add pluginval to pamplejuce so everyone starting out gets 1-click pluginval.

Note:

Technically, this feature adds an additional maintenance burden to pluginval — before this change, pluginval only had to care about working for the single JUCE version it came bundled with. Now, it would need some preprocessor #if statements to maintain some backwards compatibility with older JUCE versions (like I did in this PR for JUCE < 8.0.11)

[drowaudio]

Am I supposed to be reviewing or merging this?
I like the feature set but it seems to have not changed much in the last year? Is it stable enough to go in?

You might notice I switched to CPM for a few other dependancies on develop. Can this branch be pulled in line with that?

[sudara]

@drowaudio I've been using this branch for a year as a dependency of my synth but never got the example plugins running in CI. I'll need to get that going and resolve recent conflicts before it's mergable.

[drowaudio]

Ah ok. Poke me if/when you get to that.

I might switch to juce via CPM at some point soon anyway...

[sudara]

It's harder to grab this SHA1 when JUCE is coming from CPM. I looked at the history and decided this feature is unnecessary:

1. In most cases it's fine to bump JUCE without clearing cache
2. When bumping JUCE, the cache version can be manually bumped if desired

[sudara]

@drowaudio I merged in develop, aligned CPM, fixed the plugin tests and added tests specifically for this new type of usage (as a dependency of a JUCE project).

I have been using pluginval this way, but there is one drawback for you/us as maintainers, which is noted in the description. I won't be offended if you don't want to take that additional burden on.

[drowaudio]

I think if you're using it this way you have two options:

1. Live with everything at head
2. Stick with the version that works with the juce version you're using for your project

It's basically impossible to do anything else for libraries that don't maintain a stable API and ABI (which is very hard to do).

[sudara]

I've been maintaining JUCE 7/8 compatibility with some other open source projects and I would classify it as "mildly annoying" (for example the JUCE 8 font changes).

But yeah, I don't think pluginval itself needs to make any big promises. I haven't tested JUCE 7 and I noted in the README changes that it would be JUCE 8 only.