Some groundwork for providing alternative FileReaderWriter

First, thanks for Secor - I'm finding it useful and well engineered.

I'm in the process of writing an AvroMessageParser and AvroFileReaderWriter. I'll try and abstract what's general about these and provide in a later pull request.

Currently you have a configuration that allows the MessageParser and FileReaderWriter classes to be pluggable (with the emphasis on the MessageParser where SequenceFileReaderWriter is already somewhat generic). An Avro container file is another possibiltiy for the file output. Currently FileReaderWriter is an interface whereas MessageParser is an abstract class. This seem a little inconsistent and provides no way to enforce the contract that ReflectionUtil expects from implementations of FileReaderWriter, namely a ternary constructor. By using an abstract class at least we can more heavily hint that this is needed (although we can't stop someone from overriding with a constructor with a different signature). We could make the contract explicit by using a factory class and an `Build()` method but this would require implementing a factory class that seems an unnecessary layer. Based on this thinking this PR:

- Makes FileReaderWriter an abstract class with the desired constructor implemented.
- Changes ReflectionUtil to return the concrete MessageParser and FileReaderWriter objects rather than Object.
- Assumes a constructor matching that of the base abstract classes exists (since only that will work) in both cases, rather than searching by arity.
- Ensures that the provided classes are assignable to MessageParser and FileReaderWriter.
- Adds some ReflectionUtil tests.

I'm making this now since if you agree with the changes I'll base my Avro plugins on them.

Thanks!
I don't think the implicit constructor is needed if all sub-classes would call super() with the defined constructor below