Add a way to skip PK existence in collections

When we return instances from a collection, i we want to skip a lot of
redis calls, we can pass a "skip_exist_test" argument to True to the
"instances" method, to bypass the check of the PK's existence.
Add "values" and "values_list" to collections.

They both work as in django:
- they take a list of fields
- if no fields, use all (simple) fields of the model
- "values" returns a list of dictionnaries
- "values_list" returns a list of tuples (or a flat list if
  "flat=True" is used with a single field)

With these two commands, we can have wanted values very fast
without having to ask for instances and retrieve each wanted
field for each instance. It's **really** fast.
Enhance RedisModel.get with only a pk as kwargs

We already handled a single arg parameter, treated as a pk, to avoid
asking for a collection.
Now we also handle a pk passed a the only kwarg.

So:
    MyModel.get(1)
is now exactly the same as:
    MyModel.get(pk=1)
Rewrite collection internals

- Now, except if it's the only filter, the pk is managed as all fields, via
  set intersections (a temporary set is created for this)
- If only a pk as filter, it's existence if checked when really executing the
  collection, not before (so the lazyness applies here too)
- Sort can be applied if we only have a filter (it allows the use of values
  and values_list)
- _collection is simple, with part to create the final set to work on in a
  new method "_get_final_set"
Add tests for recent updates in model.py

- model.InitTest.test_skip_paramter_skip_existence_check
- model.GetTest.test_should_accepte_a_simple_pk_as_kwargs
Add consistency when using _skip_exist_test

Before this commit, when using _skip_exist_test to get an object
(via the "instances" method of a collection or directly via the model
constructor), no check of the pk existence were ever made.

But when setting a field, entries are created and index updated. And
if a non-existent pk, the index contains a bad pk and retrieving can
fail. Lack of consitency.

With this commit, the existence of the pk will be done the first time
an update is done on an object if we first asked to skip it.

No check is done when only getters are called (to keep the speed
gained by using the skip parameter).

To do this, the _traverse_command is now surrounded by a _call_command
which become the main entry point to call commands.
_traverse_command is the one to override to update its behaviour, as
already done in our subclasses.
Merge branch 'work-on-hmget-hmset' into enhance-collections
Add namespace for new models in tests
Test collections filtered on pk
Remove unused import in collection.py
Simplify PK check in collections.

Know we don't check for use of pk with both names on filtering, we simply
return an empty collection if the both names (ex: pk and id) are not the same
(as we use a set internally, if the both names are used with the same value,
we act as if you got only one)
Prefill "_lazy_collection" in collection.py

We fill it with "sets" and "pks", so we don't have to check for their
existence each time.
Both are sets to simply ignore non-unique values.
Move __call__ content in a new method in collection

This new method is name "_add_filters" and is simple called by the
__call__ method.

The aim of this commit is to allow easier subclassing of CollectionManager
We can now use another CollectionManager

It can be useful to use another CollectionManager than the default one, to
active a filter by default (for example only return 'active' objects...),
or to use an enhanced manager (as we'll see later in contrib.collection)

There is two way to do this.

At the model level, by assigning a subclass of CollectionManager to the
"collection_manager" attribute:

    class MyModel(RedisModel):
        # [here fields and other stuff]
        collection_manager = MyCustomCollectionManager

The other way is to pass the wanted CollectionManager subclass to the
"manager" named argument to the "collection" method.

With this, in our previous example, we can still use the default manager:

    a_collection = MyModel.collection(manager=CollectionManager,
                                      a_filter=a_value[...])

So if yu want to keep the default manager on the model, you can use a
different one when calling the collection.
Add a _prepare_sets method called in _get_final_set

The goal is to ease subclassing
Add an ExtendedCollectionManager in contrib

Located in contrib.collection, this ExtendedCollectionManager extends the
defaut CollectionManager by provinding two new methods:
- filter
- intersect

"filter" simply calls the recently added "_add_filters", and add given
filters to the list of all filters to take into account. This method
returns the current collection, so its chainable, and can be used many
times.
All the filters are "and"ed, so if a filter is set with a value in a call
and with another value in another call, you can be sure that the collection
will be empty.

"intersect" takes a list of sets that will be intersected with the ones
got from the calls to "_add_filters". It can be the name of a redis set,
a SetField, or a regular set/list/tuple. This method returns the current
collection, so its chainable, and can be used many times.

All sets for all the calls to filter and intersect will be "intersected"
in redis during the call to the collection
Allow "intersect" to accept [List|SortedSet]Field

As we can do an interstore directly on them, we have to get all their
values and store them in a temporary set.

We could add a fast way of doing this using lua in redis 2.6
Use scriping if available to copy list/zset to set

In ExtendedCollectionManager, the "intersect" method allow the use of a
ListField or SortedSetField.
But as they are not stored as a redis set, they cannot be used directly
to compute the collection (need to "intersect" the different sets)

Before this commit, the whole content of the field was retrieved locally
before its content put back in a temporary redis set. It's can take a long
time, and a lot of bandwith.

With this commit, this copy is done atomically in one redis call, using
the scripting capabilities offered by redis 2.6.
This, only if both the client (redis-py) and the server (redis) support
this feature, else we fall back to the previous way.
Add tests for scripting in ExtendedCollectionManager
Regroup sort options preparation logic in 1 place