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.



This is existing code - I've moved it from query.py or compiler.py (I forget which).

These are special cased because number handling is awkward with expressions. Sometimes you'll get a float back from the database when it should be a Decimal. The only way django knows that it should be a Decimal is because the output_field is an instance of a DecimalField.

Mixing number types like:

```
.annotate(calc=Sum('float_field')+Sum('decimal_field'))
```
.. is allowed, but django doesn't know what type to return to the user. In this case, the user will need to force both fields to have the same output_type (or wrap it in an expression where the output_field is set at the root of the tree).  The user may decide they are only interested in Decimals, and will provide the output_field as such. The database will return "96.49", but the number won't be coerced properly unless the above code is run.

Numbers in particular are special cased, because it's common to mix number types together. Adding a string to a string always produces a string. Adding a float to a decimal always produces.. what? Previous attempts at refactoring this have tried to coerce to the "highest" type.. that is:

- If there is a decimal in the expression, make the entire expression a decimal
- Else; if there is a float in the expression, make the entire expression a float
- Finally; if there is an integer, make the entire expression an integer

This doesn't work all that well in practise, and different backends (I assume, it's been a long time since I tested this), have different rules about combining numbers. I remember adding either Float or Decimal conversion to the postgres backend for all fields (not just aggregates) until mj's refactor rendered that unnecessary.

If someone can suggest a better way of handling this, I'm all ears. I agree that this particular block of code could use some love, I'm just not too sure if or how it could be improved.