[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. The new way is 30% faster on djangobench query_select_related tests.
  3) Queries now have context variable. In essence this is a store for custom per-query variables. The context is currently used only internally, but exposing it in the QuerySet API could be a good addition. Things like choosing the time zone, SRID for gis or active language could be implemented using context.
  4) Database converters now work on expressions instead of internal_type. It is of course possible to get the internal type from expression.output_field.get_internal_type(). In addition converters now have access to context.


Tests pass on SQLite and PostgreSQL. There are still some failures on MySQL. Tests likely fail on Oracle, but I haven't tested this yet.

This example surprises me as it's not transitive. I would think that a values call after an annotate call should check whether or not the item was already selected, and error if it was not.

```
SomeModel.objects.values('name', 'pk').annotate(Count('somecol')) ==
SomeModel.objects.values('name').annotate(Count('somecol')).values('pk') !=
SomeModel.objects.annotate(Count('somecol')).values('name', 'pk')
```

This behaviour surprises me because it's generally understood that values() before an aggregate determines the grouping, and values() after an aggregate just chooses the post-aggregated columns to return back. But this example suggests that a values() after an aggregate that wasn't already in the pre-aggregate list then adds to the pre-aggregate list.