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 had already looked into using a Guava cache, but I wasn't sure the eviction would be super useful in this use case. Given the nested nature of the data (i.e.: a Map<SUBJECT, BiMap<ID, SCHEMA>>), the eviction policy would eliminate complete BiMaps, rather than the least recently used K/V pairs within those BiMaps. Unless we choose to flatten the data structure into something like Map<Pair<SUBJECT, ID>, SCHEMA> but then we wouldn't have a BiMap anymore, which was pretty convenient for this.

Regarding this specific function, if we always rely on the BiMap's inverse(), as you suggested, then the synchronisation in this part of the code is not necessary anyway.

Perhaps a ```LoadingCache``` would be warranted in the places that actually make calls to the underlying Schema Repo. Not 100% sure, for the reasons mentioned above.