Add metrics for evaluating cost and effectiveness of bloom filters

Adds 3 new metrics, which are available per-table and per-regionserver: - bloomFilterRequestsCount -- how many checks against a bloom filter occurred. Note that a single read might increment this multiple times, one for each storefile it needs to check. - bloomFilterNegativeResultsCount -- how many of those requests came back negative, indicating the bloom filter helped to avoid opening a storefile which did not include the row. If this value is low, it might be worth disabling bloom filters on a table - bloomFilterEligibleRequestsCount -- increments in the same way as bloomFilterRequestsCount, but only when bloom filters are _not_ enabled for a table. If this value is high, it might be worth enabling bloom filters on the table. Additionally makes 2 existing metrics available on a per-table basis: - staticBloomSize -- uncompressed size of the bloom filters for a table - staticIndexSize -- uncompressed size of the storefile indexes for a table You can combine bloom filter request and result counts with staticBloomSize to determine if the cost (size) is worth the effectiveness (result/request count) of the bloom.