Provide access to previous constructor initializers from later ones

[nex3]

Today in a constructor, I can refer to fields initialized with this.-style parameters:

Foo(this._value)
  : _computed = _value + 1; // This works! 🎉

As I understand it, this works by creating a local variable _value that shadows the field and has the same (initial) value. However, if you want to access an explicit initializer's value from a later initializer, you're out of luck:

Foo(this._value)
  : _computed = _value + 1,
    _recomputed = _computed + 1; // This doesn't work! 😢

I propose that each initializer creates a local variable that's visible for the initializer expressions that lexically follow it, and that shadows the corresponding instance variable name just like this. parameters. This would be very useful when doing moderately complex pre-computations in constructors, and it would help avoid unnecessary factory constructors or late fields.

[nex3]

I'm dying for this in some code I'm writing right now. I could work around it with late final, but then I have to add a bunch of fields to my class for what is essentially just intermediate data. The next best option is duplicating the entire constructor into a private constructor, which adds a ton of extra code for no benefit.

[lrhn]

I'd actually rather have "declaration expressions" (#1420), an expression introducing declarations into the local scope, because it is more general if one of those could survive from one initializer list entry to the next.

Consider:

 Constructor() : sink = (var controller = StreamController<int>()).sink, stream = controller.stream;

where the value I want to reuse is not the one stored into a variable.

Could do something similar by allowing local variable declarations in the initializer list:

 Constructor() : var controller = StreamController<int>(), sink = controller.sink, stream = controller.stream;

but that's more specialized, doesn't help in other expressions, and if we're going in that direction, we might as well a full statement block as initializer, like #3002.)

But this feature is also reasonable, and simpler, so we could have both. We should have both. 😁