Associated field inheritance

Yet another servo DOM proposal, by me and @eddyb

This Proposal is about solving the servo DOM design requirements through a combination of a few  orthogonal features and extensions that are useful on their own:

- Allowing upcasting of a trait object
- Extend trait objects to include associated fields that map to fields of the implementing type
- Allow opt-in use of an internal vtable for an trait object hierarchy.
- Provide composition sugar for struct fields, and make it usable for associated fields too.
- Ability to call the default implementation of a trait method, even if a implementer overrides it.
- Ability to override associated items of a trait with default impls in a sub trait.

By combining them in the right way, its possible to model something that behaves similar to an inline-vtable single-inheritance OOP system with trait objects.

[Rendered view](https://github.com/Kimundi/rfcs/blob/associated_field_inheritance/active/0000-associated-field-inheritance.md)
The problem is that it ends up being common when implementing certain patterns.
See libsyntax's fold.rs and visit.rs.
I don't like using a keyword for this myself, especially for the initial implementation - attributes have less dire long-term consequences.