Required list load

This is a first draft of my changes that address requiring lists of elements. Let me know your thoughts!
The main issue I see with this right now is that this is doing the reflection and annotation reading _every_ time the condition is evaluated, when those values are never going to change.

Also, it's a little gnarly to have so many lambdas in this class. As the saying goes, in every class, there are at least 2 classes (or something like that). Once you breach 150-200 lines, you're looking at a red flag that you are cramming many classes into one.

I've been brainstorming on what that object graph might look like, and there are a few options. Basically, I like to think about inputs and outputs. It's easiest to start with where you know you need to end up.

__Out:__ A condition we can evaluate to determine if number of elements in the list that match some condition is within some appropriate range of values. E.g. for a list annoteated with `@Require(exactly = 1)`, whatever condition we are evaluating on the list's elements, only one must match it.

Okay, what ingredients do we need to determine this?

1. A range of values that the number of elements that match a condition is allowed to be in
2. A list of elements of some type (type could be anything really)
3. A condition that each element must meet

What do we need in order to get _those_?

1. For a range of values, we need a required annotation (or assume atLeast = 1 if no annotation is present) -- we have this.
2. For the list, we need the field that contains the list -- we have this too.
3. For the condition the element must match, that depends on what we need to know about these elements.

So number 3 is where it gets more complicated. Do we want these elements to match load conditions? Present conditions? Displayed conditions? To me, this is the variable input.

So what if we have a class that accepts 1 and 2, and then a method that accepts 3? Put them all together, construct a condition. Now the condition _itself_ can be a specific subtype too, merely to abstract away a nice `toString()` and stuff like that that is expected of a condition (which is a testing aid, so it naturally requires a good toString after all). We could even abstract it as a Hamcrest Matcher! :D

I tried a little of the above and looks like (a) some refactoring is in order for Analyzer, and (b) Matchers may be the way to go. Let's talk once I get out of training.