* Change serialization interface to be an object

Rather than passing separate serialization and deserialization methods
to a pymemcache client, pass an object implementing a very simple
two-method interface.

This is a rather significant breaking change and should be part of an
x.0.0 major release.

Resolves #56

As suggested in that issue, this is a cleaner interface, as there's no
sensible context in which you would provide only one of these two
methods and it should therefore be thought of as a
serialization/deserialization protocol.

Also adds a note to the documentation's Best Practices list that you
should use the built-in serializer object unless you have a reason to do
otherwise.

* Support "de/serializer" in addition to "serde"

In order to support older client usage in addition to the new
serialization object (protocol), restore the "serializer" and
"deserializer" arguments to the Client classes.
These are marked as deprecated and will be automatically wrapped into a
small "serde" object.

In order to make the various object names more distinguishable and more
informative, the built-in default serializer is now called
"python_memcache_pickle_serde"

Additionally, default client.serde to a "no-op serializer".
This object does no transforms on the data. By putting this in place, we
can skip some conditionals in the code around presence or absence of a
serializer and therefore simplify internally (at the cost of an extra,
unnecessary, functional call in some cases).

It also simplifies logic around the handling of flags because we are now
*guaranteed* the presence of a serializer object which returns some
flags. i.e. "default flags" are no longer the responsibility of the
various serializer usage sites.
This is done carefully to ensure that passing a `serializer` without a
`deserializer` is respected.

added flags in client functions to provide support for extra memcached operations.

The actual client tries to encode unicode and if it fails
MemcacheIllegalInputError is raised. Fix the MockMemcacheClient to do
the same thing.

Fix bug #222

Previously python2 code using python-future to backport the py3 bytes
behavior would trigger the following exception:

code:

  from builtins import bytes as newbytes
  from pymemcache.client.base import Client
  client = Client(('localhost', 11211))
  client.set(newbytes('key'), 'value')

  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/local/lib/python2.7/site-packages/pymemcache/client/base.py", line 297, in set
      return self._store_cmd(b'set', key, expire, noreply, value)
    File "/usr/local/lib/python2.7/site-packages/pymemcache/client/base.py", line 770, in _store_cmd
      key = self.check_key(key)
    File "/usr/local/lib/python2.7/site-packages/pymemcache/client/base.py", line 251, in check_key
      key_prefix=self.key_prefix)
    File "/usr/local/lib/python2.7/site-packages/pymemcache/client/base.py", line 91, in _check_key
      key = key.encode('ascii')
    File "/usr/local/lib/python2.7/site-packages/future/types/newbytes.py", line 381, in __getattribute__
      raise AttributeError("encode method has been disabled in newbytes")
  AttributeError: encode method has been disabled in newbytes

Add a test case for this and fix.

Allow binary strings to be stored as-is in MockMemcachedClient

The current MockMemcacheClient doesn't support storage of non-ascii strings as values, but the real Client does. This PR aims to close this gap between the mock and real clients.

memcached's ASCII protocol supports unicode keys, so lets support them
as well. Since using unicode keys for memcache is uncommon and to
preserve the previous behavior disable support by default.

Add .python-version to .gitignore (for pyenv)