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)
Overlapping fields would be better served by having just one trait require the field and having the other trait depend on it (or have them both depend on a third trait with that field). Besides, that's precisely what virtual inheritance does in C++ and the conventional wisdom there is just to fix your design so you don't need it.

Further, while multiple inheritance can be used judiciously, that's quite rare and virtual inheritance even more so. Worse, its implementation details are an absolute nightmare that. Despite being unopposed to MI in general, I am absolutely opposed to anything that complex in the language itself.

Associated fields ought to be very rare and multiple inheritance of them even more so, but if we need to resolve name clashes at all maybe it could be done with a `use` in the impl?