Options classes should subclass the driver options classes

[evanchooly]

Is your feature request related to a problem? Please describe.
By subclassing, we can remove a barrier to exposing new features as the driver evolves. This requires that the driver make these types non-final. A patch will be generated once work has approached completion on the Morphia side. If that patch is not accepted, then composition will be used instead. This doesn't let us track new options seamlessly but it does not rely on the driver team's acceptance of any change requests.

Describe the solution you'd like
Because of the fluent nature of the API, we'll need to override each method and return the Morphia type instead to support Morphia-specific options (read preference, write concern) not typically present on the driver types. Tests will need to be written to ensure that each method exposed by the driver is overridden with the new return type.

[evanchooly]

added a test to confirm this is done where allowed by the driver. when the driver changes the finality of certain options types, this test will start failing letting us know we can update the morphia side of the world