Fixed #14030 -- Allowed annotations to accept non-aggregates

This PR supersedes https://github.com/django/django/pull/2184 and fixes https://code.djangoproject.com/ticket/14030.

Annotate has learned to accept non-aggregates, and aggregates can now use F() objects and arithmetic, since they now derive from ExpressionNode:

```
Author.objects.annotate(combined_ages=Sum(F('age')+F('friends__age')))
Author.objects.annotate(double_age=F('age')*2)
```
 ML discussion: https://groups.google.com/forum/#!topic/django-developers/8vEAwSwJGMc

I'm going to close the previous PR which only implements the aggregates refactor. The additional commits for this PR allow non-aggregate annotation, and includes the beginnings of documentation.

There's still a little bit to be done, but I'm confident that both of these items can be completed in a fairly short timeline (within a week if required immediately):

- ~~Complete documentation~~
- ~~Implement deprecation path~~
  - ~~renamed aggregates to annotations attribute on sql/query.py~~
  - ~~sql/aggregates should no longer be used~~

I'm fairly sure the code is solid and ready for review. I admit, it's a big change. But it does increase the utility of aggregates and annotations significantly, and allows users to implement their own aggregates and expressions very succinctly.



The expression already does decide the output_type, and takes appropriate measures to cast the values from python with the convert_value method. The alternative would be producing `cast(x as type)` SQL, which would be different per backend.

Rules that make sense for model fields don't necessarily make sense for annotations.

There is precedent already for combining specific types - DateModifierNode. It requires, and calls, connection.ops.date_interval_sql on the backend. There could be a similar method for combining text. As you mention though, it'd be extremely difficult to cater for all possible combinations of arbitrary types.

We could (and probably should..) pass the expressions themselves to `connection.ops.combine_expression` rather than the string-ified expression. That should give the backend enough information to be able to determine the appropriate structure to output (like CONCAT or || for text).

These are just thoughts at the moment. The current approach (above) punts the decision of types to the user. I think it'll be a difficult problem to correctly guess all combination of types.