An object wrapping/mutating/decorating shortcut related to #40

This is highly related with #40 which is being implemented now as far as I understood. There are use cases that are not covered by the presented solutions though.

Sometimes you want to "mutate" objects of classes from external libraries and then send them back to the library, causing #41 to not be enough (it's scoped). To do so, you have to wrap the object like [this](https://en.wikipedia.org/wiki/Decorator_pattern).
There are quite a few nuisances with wrapping an object when you only want to mutate one or a few functions and the class has 30+ members. It is also not enough, since the object could have been promoted to a super class when you receive it and later it gets downcasted back (your wrapper fails in that case). You would like the wrapped object to retain all its properties and not only the visible ones, while only having a few overridden members.

Direct mutation might be forbidden, but the language could help to make it easy to create wrapped versions of the object. For example:

```
class A {
foo() { }
jaz() {}
}

wrapper W {
@override
foo() { wrapped.foo(); } // super keyword perhaps instead of wrapped
bar() {}
}

A a = A();
A a2 = W(a);
a.foo(); // calls original A foo
a2.foo(); // calls wrapped W foo
// a2.bar() compile error since type A has no bar
W w = W(a); //
w.foo(); // calls W foo
w.bar(); // calls W foo
// w.baz() compile error since type A has no bar

class B extends A { }

A b = B();
A b2 = W(b);
B b3 = b2; // possible
```

So essentially the wrapper would be an object that defers all its function calls, type checks, etc to the wrapped object. Perhaps the wrapped object could be a special type that defers all calls except for a reserved word wrapped property which points to the var that got wrapped.

In any case this could be an addition to the Static extension types of #41, where besides the casting to the extension type, the extension could have a default wrap function, which creates a wrapped object. Something like extension.Wrap(object).

In the end, all of this is currently possible, but it requires a huge amount of work, which makes the code less readable and more prone to errors. What do you think?

I ask this and access to private members in #409 because those have been essentially the stones on the road that stopped me when I began developing in flutter a few weeks ago.

Start by reviewing issues #40, #41, and #409 alongside the wrapper examples in this issue. Clarify whether the proposal belongs with static extension types or requires a separate language feature, including how wrapping, dispatch, type checks, inheritance, and private members should behave. Done means a decided, implementable language design with resolved semantics.

Written by the indexing model from the issue text.