[contib.postgres] HStorefield

Beginnings of an `hstore` implementation. TODO:

- [x] support migrations to create the extension and register with psycopg2
- [x] expand the field definition, including restriction of variables
- [x] form field
- [x] add lookups
- [x] docs
- [x] validator

There is a design decision to make: do we want a simplistic hstore field which follows the rules of hstore itself - restricts to strings and null, or do we want something a bit more clever like `django-hstore` provides that does some json encoding on non-string types? I currently lean towards the former as we will also have support for a `jsonb` field for more rich data. This would also remove a lot of complexity from the `django-hstore` implementation - descriptors, subclasses of dict etc.
This actually is symmetrical for == operator. The reason is that when a KeysValidator and sublcass of it are compared, the subclass instance's __eq__ method is always called. Hence, the isinstance(other, self.__class__) check will always return False, as other will be the parent class. This confusing rule is documented at https://docs.python.org/2/reference/datamodel.html#coercion-rules 

It is still better to write this as (isinstance(other, self.__class__) or isinstance(self, other.__class__)). The reason is that 1) the above mentioned rule is highly confusing, and 2) when calling __eq__ directly (that is a.__eq__(b)), the above rule isn't in effect.