Miscellaneous matcher cleanup

[mcculls]

• TypeMatcher is a FunctionalInterface
• Provide strong-type form of not(...)
• Introduce AccessMatcher functional type
• Add some common 'negative' access matchers

[PerfectSlayer]

👏 praise: ‏Nice change. It feels way more expressive than the IntPredicate

❔ question: ‏I read the "simple approach comment", just asking if there is any benefits implementing new lambdas over using the existing and(), or() and negate() from IntPredicate and Predicate and casting the output to the expected type?

[mcculls]

if there is any benefits implementing new lambdas over using the existing and(), or() and negate() from IntPredicate and Predicate and casting the output to the expected type?

Main benefit is carrying the type over - if you use the base IntPredicate.and etc. then the resulting lambda is of type IntPredicate not AccessMatcher. Attempting to cast it to AccessMatcher will fail with a ClassCastException. The only way to retain the AccessMatcher type is using a capturing lambda for the and.

(The other issue about implementing AccessMatcher.and on top of IntPredicate.and is that you have to cast the argument to IntPredicate, otherwise you would cause a recursive loop - so you end up with a lot more casting which is not as performant.)