Use simpleserializer with TypeLayer

After #82 I think it may make sense to drop the Encoder used by the TypeLayer and instead use the SimpleSerlializer. This will result in a more uniform and consistent user experience. It will also allow the addition of `set(Object)` and `T toObject(Class clazz)` methods.

``` java
SimpleConfiguration appConfig = ...
Transaction tx = ...
//The serialzer implementation is read from app config
TypeLayer tl = ...
TypedTransaction ttx = tl.wrap(tx);

String r = ...;
String f = ...;
long q = ...;

//some pojo type
SomePojo sp = ...

ttx.mutate().row(r).fam(f).qual(q).set(sp)
SomePojo sp2 = ttx.get().row(r).fam(f).qual(q).toObject(SomePojo.class)

//get with default value
SomePojo default = ...
SomePojo sp3 = ttx.get().row(r).fam(f).qual(q).toObject(SomePojo.class, default)
```

There are some things I am uncertain about. First I was thinking that one SimpleSerializer should replace Encoder, but then I thought about the case where want to encode key fields differently than values. For example may want to encode long types in row, family and qualifier in a certain way so that they sort properly. Also, I am thinking it should be possible to use config to get class types.

One option could be to drop encoder, replacing it with simplerserializer and optionally support using a different type of simpleserializer for key fields. This could possible be done with a builder pattern. I am not sure if I like this approach yet.

``` java
//build a type layer getting key and value SimpleSerializer type from config.
tl = TypeLayer.builder().config(...).build()

//build a type layer with a specific SimpleSerializerfor keys and get the simple serializer for values from config
tl = TypeLayer.builder().keySerializer(....).config(....).build()
```

Start by reading the TypeLayer and Encoder entry points alongside SimpleSerializer to understand the current serialization boundaries. Resolve how key and value serializers should be selected, then define the completion criteria for set(Object) and toObject(Class) before implementation; the issue does not name specific files or tests.

Written by the indexing model from the issue text.