Make TotalFacetCounts per-segment [LUCENE-4625]

TotalFacetCounts are used during complements computation today. They are not per-segment and therefore are not NRT friendly. Even regardless to NRT, you need to compute them entirely from scratch whenever you reopen IR.

It would be good if we can develop them per-segment. If e.g. AtomicReader had a notion of cachable objects, it could be such an object. That has been discussed many times in the past though, without a consensus. So perhaps we can have a FacetsAtomicReader which manages TFC. But that creates other issues too, like who instantiates that AtomicReader (i.e. we'd need a FacetsCompositeReader too, and potentially IW would need to init that type) ...

Let's explore these options, but in general it would be good to have TFC per-segment.

---
Migrated from [LUCENE-4625](https://issues.apache.org/jira/browse/LUCENE-4625) by Shai Erera (@shaie), updated Dec 13 2012

Start by reading the existing TotalFacetCounts use in complements computation and the AtomicReader-related design described in the issue. Compare the proposed FacetsAtomicReader and FacetsCompositeReader options, including who would instantiate them. Done means there is an agreed design for maintaining TotalFacetCounts per segment and a clear implementation scope.

Written by the indexing model from the issue text.