Internal: Inverse DocIdSets' heuristic to find out fast DocIdSets.

DocIdSets.isFast(DocIdSet) has two issues:
 - it works on the DocIdSet interface while some doc sets can generate either
   slow or fast iterators depending on their options (eg. whether an OrDocIdSet is
   fast or not depends on the wrapped clauses).
 - it only works because the result of this method is only taken into account
   when a DocIdSet has non-null `bits()`.

Here is a proposal to change this method to work on top of a DocIdSetIterator
and to use a black-list rather than a white list: slow iterators should
really be the exception rather than the rule.
Can not name this hasFastIterator?

I feel the name continues to encourage that such slow filters are ok. If we are planning to add support for broken iterators to DocIdSetIterator as a method (I'm honestly not sure how i feel about this), then i think the method should be something like isBroken() and should be deprecated to discourage adding more broken iterators.