Using constructor and function parameter lists as implicit parameter groups

Creating constructors may require a lot of repeated code when using super, named and redirecting constructors as described [here](https://github.com/dart-lang/language/issues/493#issue-476835353).
Although [super parameters](https://github.com/dart-lang/language/issues/493#issuecomment-879624528) made a [big impact](https://medium.com/dartlang/dart-2-17-b216bfc80c5d), there is still room for improvement.

The proposed change is

- syntactic sugar to allow referring other constructors in a constructor parameter list
- the parameters of the referred constructors are automatically expanded for the callers
- IDE wizards and autofill should support the parameter expansion
- working for _this_ and _super_ constructors
- named constructors too
- a more generic version of @Hixie ’s …super approach
- a potential answer for @yjbanov 's request on factory constructors

Example:
Current code:
```dart
class OutlinedButton extends ButtonStyleButton {
const OutlinedButton({
Key? key,
required VoidCallback? onPressed,
VoidCallback? onLongPress,
ValueChanged? onHover,
ValueChanged? onFocusChange,
ButtonStyle? style,
FocusNode? focusNode,
bool autofocus = false,
Clip clipBehavior = Clip.none,
required Widget child,
}) : super(
key: key,
onPressed: onPressed,
onLongPress: onLongPress,
onHover: onHover,
onFocusChange: onFocusChange,
style: style,
focusNode: focusNode,
autofocus: autofocus,
clipBehavior: clipBehavior,
child: child,
);
}`
```
Code with the upcoming super parameters:
```dart
class OutlinedButton extends ButtonStyleButton {
const OutlinedButton({
super.key,
required super.onPressed,
super.onLongPress,
super.onHover,
super.onFocusChange,
super.style,
super.focusNode,
super.autofocus = false,
super.clipBehavior = Clip.none,
required Widget super.child,
});
}
```
Code with the proposed feature:
```dart
class OutlinedButtonProposed extends ButtonStyleButton {
const OutlinedButton({
...super.ButtonStyleButton,
});
}
```

Code with the proposed feature on _this_ constructor:
```dart
OutlinedButton.red({
...this.OutlinedButton,
super.style = ButtonStyle(backgroundColor: Colors.red)
});

```

Advantages

- Shorter code.
- No change on the caller side
- Only the specific parts are needed in the constructors.
- Easy to see and understand overrides/differences.
- Transparent changes, no need to modify all passing constructors

Explicit and implicit parameter conflicts are resolved with the following priority policy:
1. explicitly defined
2. implicit _this_
3. implicit _super_

Notation: adding a keyword or a separator may improve clarity. Samples:

- _... this/super . constructor/namedConstructor_
- _this/super . constructor/namedConstructor . params_
- _{ this/super . constructor/namedConstructor, }_

I agree with @eernstg that positional arguments can be very tricky, further evaluation is needed whether to support them.

A similar feature is to use the parameter list of a function as a parameter group with the new notation. For example:

```dart
String foo({String left, String right, int count}){ … }
String foo10({...foo.params, count = 10}){ … }

```
Invocation is not changing:
```dart
String a = foo10(left: ‘ABCD’, right: ‘EFGH’)
```

Start with the proposal and its linked Dart language issue #493, then compare the constructor examples for super, this, named, and redirecting constructors with the function-parameter-group example. Done means reaching agreement on notation, parameter expansion and conflict rules, including whether positional arguments are supported, plus the requested IDE and autofill implications.

Written by the indexing model from the issue text.