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: 
If I understand correctly, this is currently only used for the ZK repo, since it's the only one for which ```fetchSubjectsInternal``` is overridden. The proposed implementation seems a bit wasteful: it will recreate instances that already in the ```subjectCache```. This will in turn trigger extra operations on ZK for each Subject thus created. The ZK repo is not as efficient as it could be yet, because it needs some more caching (for Schema Entries within ```ZooKeeperSubjects```). Its performance should be improved further, but it seems like this part of the refactoring is a step in the opposite direction...

Given the differences in behavior between ZK vs Local FS / In-memory, I'm not sure it makes sense to make a common abstraction for them at this point.