Allow members annotated with both @ClassRule and @Rule to be static

Hi,

This is the change discussed in #793 to allow members annotated with both `@ClassRule` and `@Rule` (whereas currently, all `@ClassRule` members must be static).

Although the change is relatively small, I've significantly refactored `RuleFieldValidator` (and renamed it to `RuleMemberValidator`). I've kept these two steps in separate commits, with one final commit to actually change the behaviour.

My changes include:
- Changing `RuleFieldValidator` from an enum to a class. I couldn't see why it was an enum: it's values were never used in that sense, and they don't really seem to semantically be an enumeration.
- Pulled the various bits of logic (controlled by flags to the constructor) out into strategy classes. Each such class has default visibility, so it shouldn't look like anythings changed to the world outside the package. These aren't individually tested, as I think the existing tests cover them well enough. I could add more fine grained tests if that's necessary, though.
- Constructed the four validators using a builder, purely for enhanced readability; it's now (hopefully) very easy to look at the validator definition and read off the logic they're validating.
- Renamed `RuleFieldValidator` to `RuleMemberValidator`, since we validate both methods and fields
- Added new tests & updated one of the strategies to allow non-static `@ClassRule` members, if and only if they're also annotated as `@Rule`.

I've referred to `@Rule` annotated members as 'test rules' in a few places, as that wording already seemed to be present in the codebase, but I'm not sure if that's strictly correct terminology (since a `TestRule` can be annotated with `@ClassRule`).

I think that covers everything - let me know if anyone has questions, or if anything needs altering for this PR to be accepted.

Thanks,
Rowan
Done - it did all seem a bit repetitious :)