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 I think overriding subject() in ZK Repo would be a good approach (at least in this first pass of refactoring, we can always try to do more later...).

Regarding the splitting of concerns between SomeRepo and SomeSubject, I think it is fairly consistent: the Repo takes care of initializing whatever is necessary in the backend, and only ever calls the Subject constructor for a subject that is already initialized in the backend. In other words, the Subject constructor only reads from the backend, but does not actually write anything.

Of course, that does mean a Subject connecting to a remote backend ends up being more expensive to construct that the File or Mem Subject constructors, but you would get the same issue with a RDBMS or NoSQL store backend.

Now that we have several backends with different constraints, it gives a good opportunity to revisit how well the current abstractions work, and perhaps comment/document how the separation of concern is intended to work. This will become more and more important as we beef up the abstracted code and leave the backend-specific implementations as lean as possible.

Thanks for driving this effort (: