Better diagnostics for orphaned selectClass() on a nested class

[kriegfrj]

I was trying to write a test for a custom extension using EngineTestKit and I was using small inner classes as fodder to feed the extension to verify that it does the right thing. This has been working for me for a while.

Unfortunately, when I started a new top-level class, I didn't notice that I had forgotten the static keyword on the the first inner class that I created in this new top-level class. I was calling selectClass() on this inner class and passing it in to EngineTestKit, and then wondering why the engine wasn't discovering any tests. It was especially confusing because I new that I had used the same technique elsewhere. It wasn't until I stepped through the resolution line-by-line with the debugger that I figured out what was going on. This obviously wasted a significant amount of my time for what turned out to be a trival issue.

It makes perfect sense that the resolver would not be able to resolve the tests in a nested, non-static class where the enclosing class has not been included. However, the way that this manifests is confusing to the user. I think it would be better if some kind of precondition violation was thrown in this situation as it is much more likely to be a programming mistake that needs attention than it is to be a legitimate scenario.

[sbrannen]

Closely related to #1736 and #242.

[marcphilipp]

Closed in favor of #242