Fixes resolving to db_field from class field name, in distinct() query.
Merge conflicts resolved.
Removed merge trackers in code, merged correctly now.
Merge remote-tracking branch 'upstream/master'
dont simplify queries with duplicate conditions
fix guide link
minor typos
Update django.rst
FileField should pass db_alias to GridFSProxy in __set__ call
fix __set_state__
if `dateutil` is available, use it to parse datetimes

In particular, this picks up the default `datetime.isoformat()` output, with
a "T" as the separator.
add some tests
fix change tracking for ComplexBaseFields
Moved pre_save after validation and determination of creation state; added pre_save_validation where pre_save had been.
Added missing reference in __all__.
Added tests for pre_save_validation and updated tests for pre_save to encompass created flag.
Added pre_save_validation to signal list in documentation.
Improved signals documentation and some typo fixes.
Fixed :module: reference in docs and added myself to authors.
Apply defaults to fields with None value at 'set' time.

If a field has a default, and you explicitly set it to None, the
behaviour before this patch was very confusing:

    class Person(Document):
        created = DateTimeField(default=datetime.datetime.utcnow)

    >>> p = Person(created=None)
    >>> p.created
    datetime.datetime(2013, 5, 30, 0, 18, 20, 242628)
    >>> p.created
    datetime.datetime(2013, 5, 30, 0, 18, 20, 995248)
    >>> p.created
    datetime.datetime(2013, 5, 30, 0, 18, 21, 370578)

It would be stored as None, and then at 'get' time, the default would be
applied. As you can see, if the default is a generator, this leads to some
crazy behaviour.

There's an argument that if I asked it to be set to None, why not respect that?
But I don't think that's how the rest of mongoengine seems to work (for
example, setting a field to None seems to mean it doesn't even get set in mongo
- as opposed to being set but with a 'null' value). Besides, as the code shows
above, you'd expect p.created to return None. So clearly, mongoengine is
already expecting None to mean 'default' where a default is available.

This bug also interacts nastily with required=True - if you're forcibly setting
the field to None, then at validation time, the None will fail validation
despite a perfectly valid default being available.

With this patch, when the field is set, the default is immediately applied.
This means any generation happens once, the getter always returns the same
value, and 'required' validation always respects the default.

Note: this breakage seems to be new since mongoengine 0.8.