Support for a serialized field (preserve data types)

Add new hstore field type, `SerializedDictionaryField`.  This field accepts optional `serializer` and `deserializer` arguments (defaulting to `json.dumps` and `json.loads`, respectively).  The field returns a `dict` object (not `HStoreDict`), and runs all data through the `serializer` before insertions into the DB and runs all data through the `deserializer` when retrieving data from the DB.  This allows data placed into the field to maintain their type (provided that the data is compatible with the serializer and that the serializer only outputs `str` data).  Additionally, by defining their own serializer functions, a user can easily put in custom logic to handle non-standard datatypes (for instance, if one was interested in serializing datetime to a specific format).

This feature made other features not possible, such as subsetting against a list of values:

``` python
# Expression will be interpreted as subsetting by key/value mapping.
Something.objects.filter(data__contains={'a': ['1', '2']})
```

I do believe that this optional functionality could be rolled into the standard `HStoreField`, but for the sake of clarity it was kept in it's own field.  Additionally, for the sake of clarity, unsupported features were left in the `TestSerializedDictionaryField` class as commented-out text (this should be removed before the pull request is approved).

This pull request is in response to [this thread](https://groups.google.com/forum/#!topic/django-hstore/AqG6seEEwx0) on the django-hstore group.
To be honest, I'm not entirely sure why `contains` lookups should not be serialized.  This makes me think that it's being serialized elsewhere possibly (it would be more advantageous to address the serialization at the source of the issue, rather than here).  Additionally, I am curious to see if other lookups such as `exact`, `endswith`, or `search` should require the same logic (and why `gt` and `lt` are exempt).