Fix bulk indexing problems with Elasticsearch 1.0

In order for ElasticUtils to work for both Elasticsearch 0.90 and
Elasticsearch 1.0 using elasticsearch-py 0.4.5, we need to do some
monkey-patching of elasticsearch-py.

In this case, calling Elasticsearch.client.bulk() returns an 'ok' field
with ES 0.90 and a 'status' field with ES 1.0. This patch sets the 'ok'
field based on the 'status' field so that the bulk indexing
infrastructure in elasticsearch-py 0.4.5 is testing the right thing and
not raising BulkIndexingErrors.

Fixes #241
Merge pull request #242 from willkg/241-fix-bulk-indexing

Fix bulk indexing problems with Elasticsearch 1.0
Add "in" action to the table

Fixes #243
Add rough docs for migrating to ES 1.0

These will be improved over time, but it shows the order of steps to
upgrade to reduce downtime.

Fixes #247
Invert Python2 checks to use PY3

six didn't always have a PY2, so this makes elasticutils work with older
versions of six.
Fix S's values_list/dict re: ES 1.0

This makes some pretty big changes.

1. .values_list() and .values_dict() will now **always** send the
   "fields" property to ES. If you don't specify any field arguments,
   then "fields=[*]". If you do specify fields arguments, then it'll
   be that list of fields.

2. Elasticsearch 1.0 changed the shape of what gets returned--all
   values are lists when you specify the "fields" property. To
   make Elasticsearch 0.90 and Elasticsearch 1.0 consistent, we
   now convert any non-list values into list values for Elasticsearch
   0.90.

Wait, wat? Prior to this commit, you'd have the following:

    # Elasticsearch 0.90
    >>> list(S().values_list())
    [(501, 'frank'), (602, 'sam')]           # values are ints and strings

    >>> list(S().values_list('id', 'name'))
    [(501, 'frank'), (602, 'sam')]           # values are ints and strings

    # Elasticsearch 1.0
    >>> list(S().values_list())
    [(501, 'frank'), (602, 'sam')]           # values are ints and strings

    >>> list(S().values_list('id', 'name'))
    [([501], ['frank']), ([602], ['sam'])]   # values are all lists

After this change, we have this (assuming id and name fields are stored):

    # Elasticsearch 0.90
    >>> list(S().values_list())
    [([501], ['frank']), ([602], ['sam'])]

    >>> list(S().values_list('id'))
    [([501], ['frank']), ([602], ['sam'])]

    # Elasticsearch 1.0
    >>> list(S().values_list())
    [([501], ['frank']), ([602], ['sam'])]

    >>> list(S().values_list('id'))
    [([501], ['frank']), ([602], ['sam'])]

If you plan to call .values_list() and .values_dict() with no arguments,
you must add "store: True" to your mappings for the fields you want to
get back.
Update migration document
Update text in CHANGELOG re ES versions
Update install requirements
Update CONTRIBUTORS
Update version for 0.10 release
Update version for v0.11 development
Added distance filter.
Added some docs.
Fix typo.
Added distance test with real data.
Merge pull request #255 from patrick91/distance_filter

Distance filter
Add Patrick Arminio to CONTRIBUTORS
Fix index creation problems

When defining a mapping, the fields need to be in a 'properties' dict.
Elasticsearch < 1.2 didn't complain about these, but Elasticseach 1.2
does.
Tweaking the version for 0.10.1 development

We're going to push out a 0.10.1 before moving on to 0.11.