Rework the converter system

Fixes #505

The goals are twofold: to simplify the registration of new converters and
to add some consistency to the conversion process, and align them with the
way converters are used in generic Spring Messaging listeners, by describing
two possible transformations: inbound, message (including contentType)->targetClass,
and outbound payload+headers -> message. The idea is for the two
transformations to match the input and output directions of the bound channels.

List of changes:

- Create and configure input/output channels distinctly - reflected
  in the definitions of `BindableChannelFactory` and `MessageChannelConfigurer`;
- Replace AbstractFromMessageConverter with bidirectional converters;
- Use the channel direction (input/output) to determine whether
  `toMessage` or `fromMessage` will be invoked;
- Use contentType support from `AbstractMessageConverter` to map
  converters to mime types instead;

Making converters more robust

Addressing comments

Convert content type headers to String before serializing

Addressing further PR comments

spring-cloud-stream-binder-test/src/main/java/org/springframework/cloud/stream/binder/AbstractBinderTests.java

@@ -239,7 +239,7 @@ public abstract class AbstractBinderTests<B extends AbstractTestBinder<? extends
 				new CompositeMessageConverterFactory(null, null));
 		messageConverterConfigurer.setBeanFactory(applicationContext.getBeanFactory());
 		messageConverterConfigurer.afterPropertiesSet();
-		messageConverterConfigurer.configureMessageChannel(channel, channelName);
+		messageConverterConfigurer.configureOutputChannel(channel, channelName);
 		return channel;
 	}