review CodecProvider/CoreCodecProvider/SchemaCodecProvider hierarchy [LUCENE-3124]

As mentioned on [SOLR-1942](https://issues.apache.org/jira/browse/SOLR-1942), I think we should revisit the CodecProvider hierarchy.

Its a little bit confusing how the class itself isn't really "abstract" but is really an overridable implementation.

One idea would be to make CodecProvider an interface, with Lucene using a simple hashmap-backed impl and Solr using the schema-backed impl. This would be in line with how SimilarityProvider was done.

It would also be good to review all the methods in CodecProvider and see if we can minimize the interface...

---
Migrated from [LUCENE-3124](https://issues.apache.org/jira/browse/LUCENE-3124) by Robert Muir (@rmuir)

Start by locating CodecProvider, CoreCodecProvider, and SchemaCodecProvider, then read their implementations and compare the hierarchy with SimilarityProvider. Done means reaching and documenting a decision on the provider abstraction and which methods belong in its interface, with the relevant tests updated if the hierarchy changes.

Written by the indexing model from the issue text.