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 most common use of associated fields will likely be to delegate them to a `TraitData` field defined alongside the trait:

```
trait Foo {
    foo_data: FooData,
}

struct FooData {
    x: i32,
    y: i32,
}

struct MyFoo {
    foo_data: FooData
}

impl Foo for MyFoo {
    foo_data => self.foo_data
}
```

(Alternatively, the FooData fields could be used directly as associated fields and all forwarded individually, but that's even more verbose).

Ideally the default would reduce the boilerplate to specifying the required associated fields in exactly one place, and then declaring that the type wants them in exactly one place. And at that point, there's really no point in explicit mappings.