Support altering index table state and honor it during query optimization
Merge branch 'master' of github.com:forcedotcom/phoenix
test for metadatascan with table name containing underscore
Merge pull request #334 from mujtabachohan/master

Test for metadatascan with table name containing underscore
Fix for issue #335, Misc secondary index fixes, Added metadata API to access index info
Update language reference to include new index commands, aggregate functions, and data types
Changing IMMUTABLE_ROWS to be a table option instead of a table type, allowing it to be set on view and existing table
Merge branch 'master' of github.com:forcedotcom/phoenix
Allow view to be declared as having immutable rows, and fix resulting issues. Fix issues with post data update for indexes when an scn is specified
Add META-INF/services/java.sql.Driver entry to automatically load driver
Revert Phoenix version
Plethora of indexing fixes/cleanup

1. Supporting multiple index mutations to multiple tables.
	Its possible (though unlikely) that the same mutation could go to multiple index tables. However,
	with just passing around a map of mutation -> string, we can't suppor this case. Changing this to
	be a Collection<Pair<Mutation,String>>, especially as we don't need the uniqueness properties
	in a map.
2. Refactor index writing/table factory usage.
	Previously, you would convert the mutation -> string pairs to htableinterfaceReferences and then
	use the passed factory to cover the cases where you didn't have a backing htableInterface for
	your reference. Now, it does the conversion inside the writer using the factory passed on creation.
	This ends up being much cleaner and easier to manage from the Indexer's point of view. This also
	helps cut down on some duplicate code :)
3. Have CoveredColumnIndexer use raw scans to get all versions.
	This covers the case where the version you want to put is no longer in the range of 'current' versions.
	Previously, we just get the current row state, but that automatically filters out 'extra' versions,
	even though they are still in the table (and wouldn't be cleaned up by the upcoming on flush/compaction
	cleanup mechanisms). Therefore, when doing a put/delete, we still need to look into the state of that row
	at that older version
4. bumping to standard version to 0.94.9
	 Necessary to include properly cleanup when we exceed the TTL but have extra versions still present in
	 the memstore, but not cleaned up by a cleaning scanner (not yet implemented, but coming).
5. General testing cleanup
6. Fix out-of-order updates
	This occurs when a put occurs in the past and needs to delete itself at the next ts.
  Also, deletes in the row needed correct handling, in terms of covering or not, for a given row
7. Adding support for ignoring checking the hbase version.
	Helpful for testing in minicluster and upcoming versions of HBase
8. Moving to using just DELETE_FAMILY markers for cleanup.
	Makes it simpler to code with no loss of generality because once an index row is invalidated (Deleted) all the corresponding
	data at that row, at that timestamp should also be invalidated. Delete_family gives us that hiding without having to
	put an individual delete marker in for each column.
	We might want to use Delete_Column markers in the future (or alternative impls), but for now there is no case where you
	would want to read the index and find an entry, but have a delete cover part of the column - the entire index entry
	(row key + columns) is the meaningful part, separated only for ease of manipulation. Deleting one of the columns doesn't make
	any sense since it invaldiates the rest of the index entry. This is where the Delete_family marker makes sense - either the entire
	index entry exists or it doesn't - partial deletes are nonsensical in the index table. It also has the added side-effect of being
	much more space efficient.
Removing the indexing hbase-0.94.9-contrib module

Moving everything over to 0.94.10-SNAPSHOT for HBASE-8809.

Currently an unreleased HBase version  - needed for correct maintenance behavior.
You can get away running HBase 0.94.9 if you write your own maintainer and don't care about
cleaning the index for 'back in time' updates. However, if you get out of order updates to
a row that goes outside the max versions, raw scanning will not return the correct results
for the current row, leading to incorrect index maintenance.... you've been warned.