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: 
I thought about this some more, and I am not sure what we should do.

Does it actually make sense to expect all Repository implementations to keep track of configs? Or at the very least, does it make sense to expect them to keep track of all configs, including defaults vs non-defaults? I think the answer to the latter is probably no, and I'm on the fence about the former.

Does it make sense for a ZK repo, or even a Local FS repo, to store all of its config internally? Is it expected to be stored persistently, or just in memory? If just in memory, then shouldn't it be implemented just once in the BaseRepository abstract class?

It seems to me like configs could be just an artifact of the REST server and (thus REST client as well), and that's it.

I am not so sure anymore that it should be added to the interface.