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)
I think two use cases of explicit mapping would be "overlapping fields" (two fields in different traits map to the same one in the struct) and avoiding field name clashes (not necessary with fields in other traits, but also the struct's own fields). But the most common case should be more ergonomic.

Admittedly there are more complexity in implementation. I do wonder if these use cases are better solved by other means. But I like that the implementer is completely free to choose *local* names.