[WIP] Fixed #24020 -- Use expressions inside the compiler; refactor select_related() implementation

This pull requests does two important changes to the ORM:
  1) The ORM uses internally expressions. SELECT clauses are expressions, ORDER BY clauses are expressions and so on. The conversion to expressions is currently done in the compiler to keep the scope of the
patch somewhat manageable.
  2) The way select_related() queries are implemented is refactored. The compiler sets up the query, and the QuerySet iterator() uses the data generated by the compiler. Previously both the compiler and the iterator calculated the select columns which resulted in a bad DRY violation (not to mention the old get_cached_row()/get_klass_info() code was extremely ugly). The new way is 30% faster on djangobench query_select_related tests.

I had to touch the way database converters are implemented. Nothing drastic has changed in there.

What works currently:
  - tests pass on SQLite and PostgreSQL. They likely fail on Oracle

What needs to be done:
  - refactor gis. It should be possible to get completely rid of gis Compiler classes, and significantly improve the way gis QuerySet is implemented. There is a lot of work to do as we have to effectively rewrite gis to use expressions.
  - fix remaining failures on non-gis backends
  - check if the patch can be splitted to more manageable chunks
Several things seem odd to me about the contract of this method:

1. The name implies that it mutates state, which it does (via `setup_query`), but then it also returns values. The relationship between these two aspects of what it does is unclear.

2. We populate `self.select` here, but then later `fill_group_by` will modify the select, and `self.select` is never updated. In effect we have two versions of `select`: `self.select` which is filled here and then not updated again (that I see, though I may have missed it), and a modified version which is passed through `fill_group_by` and eventually returned by `pre_sql_setup` and used in `as_sql`. Is there a good reason to have these two different versions of `select` floating around? If not, could they be consolidated or kept in sync?