Increase Fidelity of the sbt.testing.Framework Implementation

[dubinsky]

• when Selectors supplied include only TestSelectors and TestWildcardSelectors, filter properties to run by matching their names against the Selectors;
• added a test that actually runs ScalaCheck via the SBT Test Interface and demonstrates the (now correct) treatment of the Selectors;
• test also demonstrates two unfixable infidelities in the treatment of the nested properties;
• thankfully, ScalaCheck's implementation of sbt.testing.Framework is, unlike in some other test frameworks, shared between the platforms (JVM, Scala.js, Scala Native), so the fixes do not have to be replicated for each platform, but:
• the test needs to supply a testClassLoader: ClassLoader parameter when calling sbt.testing.Framework.runner(); on platforms other than JVM, getClass.getClassLoader is not available, so Platform.getClassLoader: ClassLoader method was added to every Platform; on platforms other than JVM, it returns null - which is fine, since on those platforms sbt.testing.Framework.runner() ignores the testClassLoader parameter anyway.

fixes #1105

[dubinsky]

@satorg any thoughts?

[dubinsky]

@satorg I am starting to suspect that the plan here is to let this fix wither on the wine like the previous contribution in this area (#1031); if this is true, and my contribution is for some reason not wanted, please say so; otherwise - what do I need to do to get this merged?

Thank you!

[satorg]

@dubinsky thank you for the PR and sorry for the long reply!

Personally, I'd love to get both PRs (this and #1031) merged ultimately. I just don't feel very confident about this ScalaCheckFramework implementation, because I personally don't use it and mostly rely on other test framework runners.

Do you think your PR complements #1031 or supersedes it completely?

[dubinsky]

Personally, I'd love to get both PRs (this and #1031) merged ultimately. I just don't feel very confident about this ScalaCheckFramework implementation, because I personally don't use it and mostly rely on other test framework runners.

Code changes have comments, tests are added that verify the change, and issue #1105 has detailed explanations. Is there anything else I can do? Are you going to involve other contributors/maintainers that are more familiar with this area or do you have specific questions?

Do you think your PR complements #1031 or supersedes it completely?

My pull request completely supersedes #1031: it handles both TestSelector and TestWildcardSelector, whereas #1031 handles just TestSelector.

Thank you!