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.



I changed the convert_value method to just return `value` and ran the appropriate tests on postgres and mysql. See the results https://dpaste.de/xtHF and https://dpaste.de/msO9

Note, in particular, the mysql failure for `test_aggregation_expressions`:

```
a1 = Author.objects.aggregate(av_age=Sum('age') / Count('*'))
self.assertEqual(a1, {'av_age': 37})

======================================================================
FAIL: test_aggregation_expressions (aggregation.tests.ComplexAggregateTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/django/tests/aggregation/tests.py", line 733, in test_aggregation_expressions
    self.assertEqual(a1, {'av_age': 37})
AssertionError: {'av_age': Decimal('37.4444')} != {u'av_age': 37}
- {'av_age': Decimal('37.4444')}
+ {u'av_age': 37}
```

The test expects an integer result because both the left and right hand sides resolve to integers. There are two issues here, one that I was aware of, and a new one I've just picked up.

The new issue is that I never really accounted for integer division. I assume that if both sides of an expression are the same type, then the result should be the same type by default. The user can override this, but we may need to revisit this. Ideas most definitely welcome.

The issue I was trying to highlight though, is that the result should be a **float**, but the database returns a **decimal**. The backend has no information to be able to determine what the return type should be, which is the problem I was trying to explain (poorly). I changed the assertion to expect `37.4444`, but still complains that floats and decimals are different types.

With regular fields, the migrations (or syncdb..) ensures that the column is created with the appropriate type. This gives the database and django enough information to be able to return and identify the correct type of the field.

With expressions though, the type is *dynamic*. The return value is predicated on how the database itself does conversions between types. There is no database column that tells the database what the type should be.

Django fields are not enough. We could single out "misbehaving" databases and convert all FloatFields to float for mysql (as the test case above shows), but then that conversion happens on all non-expressions, and we'll get a lot of unnecessary overhead.

The idea that we should create a test that stress tests all field types and combinations is a really good one. It'll help identify any weird edge cases or misbehaving backends. But I still think the converters in expressions are necessary, especially for these number types.