Phoenix-180

A fresh pull request with all the changes for guideposts. 
Tested in a single cluster for different combinations. 
"SELECT count(*) FROM  %s WHERE host='CS' AND domain='Apple.com' AND FEATURE >= 'Dashboard' AND FEATURE <= 'Report';" % (table)) 
With 5000000 rows
Withoutpatch
===========
COUNT(1)
----------
    555169
Time: 2.264 sec(s)
Withpatch
=========
  COUNT(1)
----------
    555169
Time: 0.813 sec(s)

Withoutpatch
==========
  COUNT(1)
----------
   1002201
Time: 1.889 sec(s)
Withpatch
==========
  COUNT(1)
----------
   1002201
Time: 1.075 sec(s)

Am sure we would get better results if we are able to tune the guidePosts width so that instead of fetching in the range of 1000s inside a region we can fetch 10ks of result in every chunk.  Also should work with bigger tables and more rows.
The tests were performed with 256*1024 and 1024 * 1024 as the guidepostsWidth size. 
The main thing you can observe in the above case is that the query targetted to single region is parallelized and distributed to smaller chunks and so the work done by every thread is less. 
We'll need to do this TODO, as otherwise the HTable won't be found for views/multi-tenant tables. For example:

            PName tenantId = connection.getTenantId();
            TableName tableNameNode = statement.getTable().getName();
            String schemaName = tableNameNode.getSchemaName();
            String tableName = tableNameNode.getTableName();            
            // This will refetch the table from the server if necessary, including re-fetching the stats
            ColumnResolver resolver = FromCompiler.getResolver(statement, connection);
            PTable table = resolver.getTables().get(0).getTable();

           byte[] physicalName = table.getPhysicalName();
           
           // Query here for last_stats_update_time

            if (table.getStats().getLastUpdateTime() 
            return new MutationState(0,connection);