Issue #20 - hashjoin implementation

1. JoinCompiler:
    Basically organizes conditions in "on clause" into three categories: a) join conditions, b) pre-filters that can be done with scan filters; c) post-filters that should be applied against the joined result.
    Also provides facilities for re-constructing a subquery out of a join table, testing star-join types, etc.

2. Runtime projection:
    One of the biggest problem with join is column name conflicts in a joined result. Currently we are using column family renaming strategy by prefixing column families with its corresponding table name (or table alias name).
    Since each KeyValue in the merged list of KeyValues from multiple tables has to have identical RowKeys (for binary search in class Result), the RowKeys of each KeyValue are replaced with a dummy/meaningless RowKey during projection. Thus, RowKeys will already have been uniformed at join time.
    As to the original RowKey itself, it will be transformed into a independent KeyValue with a dummy RowKey, a tablename prefix as column family, and the real RowKey as column value.
    Hence, when a reference to a RowKey with tablename, it will be translated into a KeyValueColumnExpression with an accessor instead of a RowKeyColumnExpression.