#14030 Annotations 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.



This seems problematic. What happens if you do this:
```
    reused_f = F('pk')
    qs1 = Model1.objects.filter(pk=reused_f)
    qs2 = Model2.objects.filter(pk=reused_f)
```
By my reading the reused_f will be first prepared for qs1, getting Model1.pk as col. Then the same object is reused and prepared for qs2, this time the reused_f's col is overwritten with Model2.pk.

The ExpressionNodes must be either stateless, or they must be copied on prepare(). Doing the latter will be easier. A basic copy method could do the following:
```
def copy(self):
    copy = Empty()
    copy.__class__ = self.__class__
    copy.__dict__ = self.__dict__.copy()
    return copy
```