Codecs, take two

There are a lot of commits in this pull request, but they share a common sets of themes:

* Completing the bson module
* Shrinking core so that it only depends on the bson module, and reducing the need for passing custom encoders and decoders to operations

To that effect there are a bunch of related changes here:

* Implementation of a new CodecRegistry that replaces the existing Codecs. The big realization I had when doing this is that the reverse mapping from BSON type to Class type does not belong in the registry.  Rather, it's a property only of a Codec that actually needs it.  And the only ones that need it are for Map-based documents with open type systems (e.g. Document).  The registry becomes very simple.  Just a Map from Class<T> to Codec<T>.
* Created a closed type system for a BSON document.  This models what's in the .NET driver pretty closely.  The root class is BsonDocument, and there are new classes for every other BSON type that didn't already have one, e.g. BsonArray, BsonInt32, BsonBoolean, BsonNull, etc.
* Following on that is a BsonDocumentReader and BsonDocumentWriter, which allows you to convert any object with a Codec to a BsonDocument, and vice versa.  
* Rounding it out is the BsonDocumentWrapper class, which extends BsonDocument and is basically an adapter from an instance of T and an Encoder<T> to a BsonDocument, which is useful when an API expects a BsonDocument and you have a T.  
* With these building blocks, I then changed all Operation implementations to use BsonDocument instead of Document.  So now there are no dependencies from core on Document, which I think is correct.
* The last piece, not that there is a registry, was to remove field name validation responsibility from Codec implementations into BsonWriter implementations.  This was done with a general purpose FieldNameValidator interface, with actual implementations in the same package as the various RequestMessage implementations.
Is there a test for this?