The new scheme insures a much more stable and efficient behavior in case of low
memory given by the user compared to the size of the buffer or 'odd' basket
layout.

The basket collection is now done in 4 phases:

  1 - One basket per branch, basket must contains the request entry and is not
      yet loaded or used,
  2 - Even out by adding baskets so that all branches reach the same entry
      (or close)
  3 - Add the remaining branches from the current cluster.
  4 - Add the basket from the begining of the clsuter to the current entry
      (if any)

then repeat the 4 steps for the next cluster.

The iteration is stopped as soon as the cache is 'full' as defined by these
rules:

 - During step 1 of the first cluster, continue up to 4 times the user requested
   cache size
 - During steps 2 to 4 of the first cluster, continue up to 2 times the user
   requested cache sizep
 - During steps 2 to 4, the 'first' basket of a branch is accepted up to 4 times
   the user requested cache size (i.e as if it had been selected during the 1st
   step)
 - During the other clusters, continue up to the user requested cache size

A basket if rejected/skipped if its individual size is larger than the user
requested cache size

In addition, upon seeing a cache miss, FillBuffer now detects if all the basket
in the cache have already been used (read from the cache) in which case we can\
discard them and load the next set of baskets.

As a side effect, we now keep a record of which baskets are in the cache and
which of those baskets have been used.  The TTreePerfStats now keep a complete
log of all the basket that are:
   - loaded in the main cache (and how many times)
   - loaded in the 'misss' cache (and how many times)
   - used
   - read directly (complete cache miss)
This will be helpful in understanding situation of over-read or slow operations.