Constructor specific generics

A broader version of #276

## Problem

Currently, generic parameters are defined only on the class level.

But in some situations, a specific constructor may want extra generic parameters (which don't have an impact on `runtimeType`).

[Consumer] vs [Consumer2] or [Consumer] vs [Selector] from [provider] are good examples of such use-case.
Same thing with [ProxyProvider] vs [ProxyProvider2]

Currently, due to the lack of constructor specific generic parameters, the different options are split into different classes. But ultimately, the implementation of these different classes is _the same_.

An abstract example of how these duplicates currently work is:

```dart
abstract class _BaseClass {
_BaseClass(this.callback);
final Widget Function(BuildContext context) callback;
}

class Concrete1 extends _BaseClass {
Concrete1(Widget callback(BuildContext c, T value))
: super((c) => callback(c, doSomething(c));
}

class Concrete2 extends _BaseClass {
Concrete2(Widget callback(BuildContext c, T value, T2 value))
: super((c) => callback(c, doSomething(c), doSomethingElse(c));
}
```

### Proposal

The idea of this proposal is to allow _named constructors_ to have extra generic parameters:

```dart
class MyClass {
MyClass();
MyClass.named(B b);
}

Start with the proposal in this issue and compare it with the broader version in #276. Review the Consumer, Consumer2, Selector, ProxyProvider, and ProxyProvider2 examples to understand the duplicate APIs being discussed. Done means reaching and documenting a language-design decision about generic named constructors.

Written by the indexing model from the issue text.