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.



Ok, the code which is adding `annotation.convert_value` looks good. The code which is *in* `annotation.convert_value` looks like it ought to be unnecessary, or at least needs to be abstracted elsewhere. Out of interest, what happens if you replace this method with an empty function? At a guess the majority of tests will still work on "well behaved" backends, and we may get a couple of failures on "badly behaved" backends.

I know that the current code can be a little heavy handed in some places with when it applies converters, doing so in any case where one might be needed. Given there is a performance implication, we want to do as little converting as possible (except on Oracle where we basically need it on every field every time due to the blank/null issues). It would be really nice to have a complete test suite of every field type used as a field, an annotation, aggregation etc. and ensure they all have the correct python type.

Perhaps we will find that the converters necessary vary a lot depending on how they are loaded. We may then want a way to ask a database backend what converters may be necessary for a given data type when loaded with an annotation/aggregation.

*[Sorry this rambles a bit, and I'm not quite sure what we actually need. Suffice to say, special casing internal types like this is now a bit of a no-no, we need to ask the field and the backend whether they need to do anything so custom field types still work]*