Issue 15 + Refactoring

I've made fairly significant changes to the class hierarchy and I'm in doubts whether they are to the better.
Please ignore the status and config part for the time being and let me know if the *Repository changes make sense. Specifically, I tried to extract common subject registration/lookup logic into AbstractSubjectValidatingRepository and succeeded for for InMemory and LocalFileSystem but with Zookeeper I was afraid to significantly alter the flow of the code and finished up using the new base class in a somewhat awkward manner. The tests pass, but I don't feel terribly good - so any comments, whether positive or negative will help :smile: 
Yeah, good name. It helps reason about what kind of abstraction it is. So then this provides common code for all Repo implementations that would store data in some "backend" (currently, the local filesystem, ZK or an in-memory hashmap).

That being said, I think we need to better define the abstractions we're introducing. Let's make sure their contract is very clear and that it is actually consistently implemented by the three current extensions of the class.

I'll comment more precisely below.