enable @AnalyzeClasses annotation to be used as meta annotation

[mathze]

so far users are forced to repeat @AnalyzeClasses annotation an every test class. This cause additional maintenance overhead when common properties (e.g. package structure) changes. To support the DRY approach, @AnalzyeClasses annotation can now be used as meta annotation.

Resolves: #182

[codecholeric]

Thanks a lot for your support! 😃 The PR looked really nice to me 👍 I still just made some changes, but that has nothing to do with the quality. In particular:

• I adjusted the style in some places to be closer to existing code
• I integrated AnnotationFinder into ReflectionUtils - I have mixed feelings about this, because on the one hand it's nice if not too much is mingled into ReflectionUtils. But on the other hand, it felt a little bit unmotivated why so many actions related to Reflection are in there, just this specific annotation handling is outside. We might need to split ReflectionUtils up at some point if it grows too much, but so far it feels like it's still alright to me
• Biggest change in logic I did was removing the exception if multiple @AnalyzeClasses are in the hierarchy. While I really like the approach to be defensive and potentially poking users into a mistake they made, there is one reason that brought me to think we should just look for the "first" one and use that no matter what: for JUnit 5 we could just use the AnnotationSupport provided by JUnit Platform and we wouldn't have to maintain any code. As far as we maintain JUnit 4, I guess it's fair to support this feature also there. But, if we one day drop JUnit 4 support, because the user base got really small, then having a stricter behavior than JUnit Platform's own AnnotationSupport would prevent us from using that. Furthermore, I think in most cases this shouldn't be a problem, I can't imagine users going crazy on using the meta-annotation support in whatever nested way, so I think this is more a theoretical confusion. If we really get issues about users being confused, because they shot themselves in the foot with confusing meta-annotation combinations in the same hierarchy, then we can still ponder if we need to do something more. But I assume this just won't happen.
• I added a section in the user guide 🙂 I think the feature is very nice, so we should make sure users can easily find out about it

In any case, I just went ahead and changed this, I really hope you don't mind! It's mainly because I have a hard time these days to make time to work on ArchUnit (as you might notice by the delay of this review 🙈), so having a lot of round-trips on the review would likely slow down the merge considerably. If there is something really wrong with the final state, we can still fix it in a follow-up.

[mathze]

Hi @codecholeric,

don't worry, I'm glad that it made it into code :) and I could support. I know maintaining OSS isn't an easy job especially if done in sparetime.
Thank you very much for your effort ❤️.