Subscribers should parse & process using explicitly registered compatible types.

Before this change, when a 1_0 message is registered with a handler and/or
target class and a more recent minor version, 1_1, arrives at the subscriber:

- 1_1 may not be in the subscriber's namespace because it doesn't yet have
  an updated set of schemas. Result: subscriber drops a message it can
  process.

- The subsriber has an updated set of schemas, but 1_1 is not registered
  with a custom handler. It can't find a custom handler for 1_1. Result:
  subscriber drops a message it can process.

Here are the primary implications of this change:

- A 1_1 message written to the wire will now be handled by the 1_0
  message and the associated handler explicitly registered in a
  subscribing application. This will happen even if the 1_1 class isn't
  in the subscribing application's namespace.

- If the subscriber application wants to begin using changes in 1_1,
  then it has to explicitly register a handler against 1_1 instead of
  1_0. This prevents a message-parsing-compatible change to the schema
  from being processed by a handler that hasn't been built to handle
  the change in backwards-compatible way.

- We will *always* parse a later minor version with the minor version
  registered within the subscriber application. This is possible
  as long as we use Protocol Buffer schema evolution rules here:
  https://developers.google.com/protocol-buffers/docs/proto#updating.
  The registered minor version is the object that will be passed
  to its associated registered handler.

When a message comes in we now do the following:

1) We find a compatible, explicitly registered message type (e.g. the
   same base type on the same major version)
2) Use that type to both parse the payload and pass to its registered
   handler.