CachingCollector.create(boolean, boolean, double) is trappy [LUCENE-4372]

Followup to #4175.

Shai proposed a method that just caches all scores so they can be replayed:
> Do you think we can modify this Collector to not necessarily wrap another Collector? We have such Collector which stores (in-memory) all matching doc IDs + scores (if required)\. Those are later fed into several processes that operate on them (e\.g\. fetch more info from the index etc\.)\. I am thinking, we can make CachingCollector optionally wrap another Collector and then someone can reuse it by setting RAM limit to unlimited (we should have a constant for that) in order to simply collect all matching docs + scores\.

But Mike had concerns about the RAM usage:
> I'd actually rather not have the constant – ie, I don't want to make
> it easy to be unlimited? It seems too dangerous\.\.\. I'd rather your
> code has to spell out 10\*1024 so you realize you're saying 10 GB (for
> example)\.

My concern here is what happens when you dont specify enough, I think those hits are just silently dropped (which is worse than using lots of RAM).

---
Migrated from [LUCENE-4372](https://issues.apache.org/jira/browse/LUCENE-4372) by Robert Muir (@rmuir)

Start by reading the discussion in this issue and followup #4175, then inspect the implementation and callers of CachingCollector.create(boolean, boolean, double). Determine the intended behavior when the RAM limit is exceeded and whether wrapping another Collector should be optional; the issue is done only when that behavior and the API are agreed and covered by the relevant tests.

Written by the indexing model from the issue text.