For consideration for v3.0.0

'cas' is documented as needing to be an int or bytestring of the digits
0-9. However, this is not actually enforced and it is possible to pass a
value to pymemcache which doesn't conform to these rules. In fact, you
can do weird things like `cas=b'noreply'` and potentially trigger
"unexpected" behavior.

To go along with validating int inputs, validate cas inputs. However,
these are not necessarily integers. Instead, if an int or string is
given, it will be encoded as a bytestring. But in order to validate the
value given, it is checked against isdigit() .

(NB: You could also use `int(cas)` for very similar checking.)

Rationale for allowing non-integer inputs to cas is not obvious.
Presumably it allows callers using `gets()` to pass the `cas` value they
get back into a `cas` command without issue. But it may be debatable.

* 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.

If a caller tries to send
- a fractional expiration time
- a string for the "incr" command
- delay=None (instead of delay=0)

The pymemcache base client will now catch these usage mistakes a
throw a MemcacheIllegalInputError.

Although there are existing valid (but undocumented) usages of the
current string conversion behavior, the docs state that these values
are supposed to be ints. Now if a non-int value is used, it will
immediately trigger an error.

This behavior is superior to the prior behavior especially in the
case where a command is used with `noreply=True`. It can fail to
parse, but the client won't pick up on this until the next call to
memcache which reads the reply.

The especially bad case we're seeking to avoid is this:

    from pymemcache.client.base import Client
    client = Client(("localhost", 11211))
    client.set("foo", "bar", expire=1.5, noreply=True)
    client.get("foo")  # triggers MemcacheUnknownCommandError

Applies to all commands using `expire`, `delay`, incr and decr
inputs, and memlimit.

Because this is can be a breaking change for some users, the changelog
entry is written under 3.0.0 (unreleased).

closes #240

When defining `long_description` in setup.cfg using the `file:`
directive, we need to keep everything on one line. Otherwise, it will
treat the value as a block of literal text.

We introduced the ability to override the serializer-returned flags
values in 26f7c1b1. Unfortunately, there was a flaw in that logic which
resulted in the first item's flags being used for all later items. This
bug primarily affected set_many()'s behavior when the data dictionary
contained multiple different value types which were assigned different
per-value flags values by the serializer.

For example:

    set_many({'a': 'string', 'b': 10})

If a serializer returned different flags for strings (e.g. 1) and
integer values (e.g. 2), the previous logic would have set ``flags``
to 1 the first time through the loop and repeated that value for the
second item, instead of using 2.

This was the intended behavior when ``flags`` was explicitly passed to
set_many(), but not for the default case where we still want to respect
the flags values returned by the serializer.

Since setuptools 30.3.0 we can use setup.cfg to configure package
for build and distribute. These changes propose to adopt a more
modern approach to package pymemcache by using latest and stable
feature of setuptools.

Overview:
- remove python code to maintain
- introduce package metadata,
- centralize version management in package metadata

We can no longer import the __version__ attribute because there is no an
implicit runtime dependency on six (as of #197), and we can't guarantee
that six is installed until *after* setup.py is parsed and run.

Instead, parse the `__version__ = 'x.y.z'` string from __init__.py to
extract the version.

Fixes #214