expose default options and serializers

[ZoeyR]

This is a very early PR that explores if its possible to expose the Serializer and Deserializer in a way that would allow us to expand options in the future.

Basic Design

• expose the DefaultOptions and OptionsExt traits publicly.
• expose Serializer and Deserializer publicly.
• keep all other traits and structs Compound, Options private

I believe this would allow us to implement any future improvements in a backwards compatible manner. OptionsExt can't be implemented by 3rd party crates since it is sealed, so adding new methods should be fine.

Remarks

• A custom ByteOrder trait was created that provides a thin wrapper over the byteorder trait.
  This enables us to add features to our endian behavior in the future without breaking the public API. e.g. making varint respect the endian choices.

Unanswered Questions

• How should this be integrated with the current config() API?
• Who (if anyone) is using the non-public SerializerAcceptor trait, and does this make that obsolete?

Tagging @jdm since (I think?) you would have perspective if servo is using these non-public APIs
Tagging @dtolnay since you had significant input on the current config implementation

[jdm]

Servo only relies on official public APIs to my knowledge.

[ZoeyR]

Great to hear! I realized this makes the unwieldy config_map macro obsolete. Previously the match statement would have exploded exponentially, but now we won't need it.

[VictorKoenders]

One of the things I dislike is that a caller has to import both DefaultOptions and OptionsExt, which might cause for confusion. This could be improved in two ways:

• Make defaults for multiple combinations (e.g. BigEndianNoLimit, LittleEndianBounded)
• Duplicate all methods on DefaultOptions so the trait is not always needed (might cause conflicts?)

Note: a lot of crates do this, it seems acceptable to just let this be.