Fix issue #9: Strongly-typed APIs

Hi,

This is a proposal for enriching the user experience of interacting with a schema repository.

A new module, ```schema-repo-api```, is introduced which provides a ```TypedSchemaRepository``` class and some common ```Converter```s that can be used with it. The ```TypedSchemaRepository``` is generically typed so that users can reliably and efficiently deal with the types they're interested in rather than Strings.

The API is also simpler than the current ```Repository```/```Subject``` class composition. Users can get whatever they want directly and in the right type (be it an ID, a schema or a list of subjects) without needing to deal with the intermediary abstractions.

Regarding APIs, please note that I have excluded the ```registerIfLatest``` API from this PR because I am not convinced it is worth exposing this to end-users, and its semantics are unclear (the exact behavior is not entirely consistent across the code base). I'd like to evaluate the eventual inclusion (or exclusion) of the ```registerIfLatest``` API in a separate discussion. I believe the current set of proposed strongly-typed APIs should be merged in as is, even if ```registerIfLatest``` is excluded in the first iteration.

This is intended to be a building block towards creating an open-source self-service Kafka encoder/decoder implementation that allows versioned pub/sub without the headache.

As part of this work, the ```schema-repo-avro``` module was also introduced. This module contains an Avro-specific implementation of the ```Converter``` interface. It is isolated in its own module in order to keep the rest of the Schema Repo project serialization-agnostic. The ```schema-repo-api``` depends on ```schema-repo-avro``` for its tests only, but not for the main code.

Speaking of tests, some basic unit tests were written, but more should follow. That being said, considering the size of the changes involved, I'd like to merge this first iteration sooner than later, before it becomes too big. Once the new strongly-typed APIs are approved and merged in, then we can add more tests for all cases.

N.B.: The older String-based APIs remain available and it is not my intent to eliminate them. If anyone already has some code using those APIs, they should be able to continue doing so.

All comments and feedback welcome (:

Thanks!

-F
I see. Yes, I think you're right. I'd argue that even if there's only one cache (using inverse as needed) there's still a race conditions possibility, **but** since there is no underlying data mutation here (unlike the below mentioned register case) it's totally fine and does not require any synchronization.