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 should decide the output type. If the database generates something different, then Django needs to either convert the database value, or preferrably use different SQL for the backend to produce directly the correct value.

What we need here is some machinery that decides what is the correct output type for field types A and B for given connector. The problem here is 3rd party fields. For example, how do we correctly guess the type of IntegerField / CustomCompositeField? In addition we need ability to produce different SQL per field type, per backend: TextField() + TextField() should produce || connected SQL. Finally we need the ability to ask the backend for a converter for the expression.

These are non-trivial problems. I think we have to solve the situation in some simple way, and deal with the above mentioned problems later on.