[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.
That seems rather opinionated to me. It depends on what your design is and whether you are treating your hstore as a kind of extended schema, or whether you are actually allowing free extra data. For example, you might want to use it to store the metadata associated with errors reported when interacting with an external API - then you have no idea what keys or values could appear, or the set is too large to make restriction a reasonable choice.