Fix typo with the serializer work

Change-Id: Ia94d0722ecf80958932a9e6f1617ec47a5bfcbb1
Make the base RPCServer class private

There's no point in this being public since the executor interface is
private.

Change-Id: I452c12c5086a65c2d554c88fd2b8a280290270ef
Make rpc.dispatcher private

This is just an implementation detail of the public EventletRPCServer
and BlockingRPCServer classes.

This is important because I'm not sure we've got the right separation
of concerns between executors and dispatchers yet:

  http://lists.openstack.org/pipermail/openstack-dev/2013-June/009934.html

  That implies that you need to pair a tulip-aware executor with a
  tulip-aware dispatcher. We'll probably need to do something similar for
  eventlet too.

I think we need the RPC dispatcher to just know about RPC specific stuff
and there's a single abstraction for I/O framework integration.

Change-Id: I5c43ec708b50d9be1abf6adaafe34f7917bf6d3a
Dispatch methods in their own greenthreads

This mimics what we do with amqp.ProxyCallback.

It might be nice to have errors like "no such method" and "unspupported
version" raised before spawning a greenthread, but that would mean
either turning the dispatcher into a two step lookup/invoke interface or
having I/O framework specific dispatchers.

Change-Id: Id4d9bd097281bb6abe8f298119726ad4bc58a4ad
Make endpoint.target optional

If an endpoint has no target set, or if it is set to None, just act
like the target is Target(namespace=None, version='1.0')

Also, refactor the dispatcher's inspection of endpoints a little.

Change-Id: Icac4464646cc9174539d5200a8bbfb652b03dc36
Allow specifying a serializer when creating a server

Since the dispatcher class isn't public, we need to allow this to be passed via
the server constructor.

Change-Id: I254175416a07731ce4e2aa66d23fef921a54d2d0
Expose Serializer from top-level namespace

I guess the idea is that users of the API shouldn't have to import
specific modules other than I/O framework specific modules.

Change-Id: I342a14b4892e227dd56a247940a8aa7d9da0d452
Allow all target attributes in client.prepare()

There's really no reason not to - you could have a single client object
invoking methods on a variety of different targets so long as they're
all available via the same transport.

Change-Id: I1acc208b5b377346416ab901666bd14a996841d1
Fix version_cap typo

Change-Id: I034f11db1a93cca7db7ca5fccf1df8cd49aa904a
Fix client.cast() typo

Change-Id: I503e8728b300aa7406c62d1a0f465e449a5e91b9
Fix defaults for client.prepare() args

None is a legitimate value to pass in for any of these args, so use a
marker object to distinguish between None and "no value supplied".

Change-Id: I99666a5c35c90a1c717ce6021bdfad1cf0ba7240
Document the public RPC API

I think I've covered everything that's public, which actually turns out
not to be a whole lot.

Still need to document the notifications API.

Change-Id: I6f07631b7c797c198a7a6a43b63c706d67521dd0