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: 
What's the goal here? Creating an in-memory instance representing a handle to a Subject that is already materialized in the backend? Or is it also responsible for bootstrapping the Subject in said backend? Alternatively, is it supposed to work both ways? (i.e.: it checks if the subject already exists in the backend, and if so, loads it, or else, bootstraps it).

The reason I'm asking is that currently:
* In ```LocalFilesystemRepository```, ```createSubjectInternal``` initializes the subject's directory and then instantiates a ```FileSubject``` which loads its state from that directory, whereas ```registerInternal``` is not overridden (and thus does nothing).
* In ```ZooKeeperRepository```, ```createSubjectInternal``` does no more than instantiate the ```ZooKeeperSubject``` but leaves the rest of the initialization work to ```registerInternal```.

Is there any point in separating the two? If we want them separate, then can we make the contract of each very well defined so that a certain type of task is always done in the same place in every implementation?

-F