Avoid allocations in IterableUtils.frequency and countMatches

[nishantmehta]

What

IterableUtils.frequency and IterableUtils.countMatches each built a lazy filtered-iterable pipeline just to count elements:

// frequency
return size(filteredIterable(emptyIfNull(iterable), EqualPredicate.equalPredicate(obj)));
// countMatches
return size(filteredIterable(emptyIfNull(input), predicate));

That allocates a FluentIterable decorator and a filtered iterator (plus an EqualPredicate for frequency) on every call. Since frequency backs CollectionUtils.cardinality and countMatches is a commonly used utility, the cost is paid on hot paths.

This counts directly in a single pass. The matching semantics are preserved exactly:

• EqualPredicate.equalPredicate(obj) evaluates Objects.equals(obj, element), and equalPredicate(null) matches null elements — so Objects.equals(obj, element) reproduces it including null handling.
• FilterIterator advances using predicate.test(element), so the loop calls predicate.test for the same effect.
• emptyIfNull's null handling becomes an explicit null check.

The direct loop also lets the JIT scalar-replace the iterator.

Benchmark

Measured with a ThreadMXBean allocation driver (200k warmed ops):

CollectionUtils.cardinality   52 B/op -> 0 B/op
IterableUtils.countMatches    66 B/op -> 0 B/op

Testing

CollectionUtilsTest (161) and IterableUtilsTest (42) pass unchanged.