Improve unsupported feature identification - Subqueries, CTEs and Functions

[onderkalaci]

Hey @jasonmp85 ,

• For subqueries we need to make two checks, which we discussed earlier:
  1. One for queryTree->hasSubLinks == true
  2. One for rangeTableEntry->rtekind == RTE_SUBQUERY
• For the common table expressions, I added a new check. In the query struct, there is a queryTree->cteList field. Wherever a CTE exits in a query (SELECT,FROM or WHERE), the field is updated.
• Since we do not support CTEs at all, it is OK to check that variable. Also, it becomes unnecessary to check it in range table entries iteration.
• I think we also need to disccuss functions. For the functions which appears in SELECT or WHERE clause, we can plan the query and get correct results (as far as I observed).
• However, for the functions which appears in FROM clause, we fail to plan and execute the query. Thus, I explictly added a check for rangeTableEntry->rtekind == RTE_FUNCTION. Could I be missing anything on that?
• I added unit tests for each case. Also, tests for common table entries were erroring out wrong, reporting that "Joins are unsupported". I also updated that error report too.

fixes #14 fixes #46

Review tasks:

• [x] Update messages and details with provided text
• [x] Change tests to use uppercase keywords
• [x] Remove extraneous space in tests

[coveralls]

Coverage decreased (-0.02%) when pulling ad4f92da7d94e5c9e29378b50cc0735a63d3b30d on feature-issue#14 into f1490b4c4fac84010eaf0d73b10e08d74c26ee1b on develop.

[jasonmp85]

Looking over these changes there's very little you need to do before shipping this. Because you're touching all the error messages I've given feedback about those, but other than that, looks good.

As far as functions go, they can appear within the FROM clause, either returning single values, a series, or sets of records (a "function scan"). We don't currently support any of these cases (in fact if we find one I'd be surprised if there weren't also a join node somewhere), so the check you've added is correct. If they appear elsewhere (SELECT, WHERE) the query can be planned and executed, with some caveats (#47).

So address the three checkboxes I've added up top and :shipit:!

[coveralls]

Coverage decreased (-0.02%) when pulling 0186784638d7ab89bf9d1b62a0f1282af1b6d5b0 on feature-issue#14 into c56862e84d055d8c7d4f19c74c1c7dc9664735b6 on develop.