Functions downcast

Consider the following definitions:

```dart
void foo(int a, String b) {}

typedef MyCallback = void Function(int a, String b, double c);
```

Currently, we cannot assign the function `foo` to `MyCallback` and instead have to write such closure:

```dart
MyCallback cb = (int a, String b, _) => foo(a, b);
```

This proposal is to allow such assignment:

```dart
MyCallback cb = foo;
```

### Reasoning

While the current behavior is technically correct, it makes adding parameters to a callback a breaking change.
And at the same time, it is common to not care about some parameters passed to a callback (hence why we have `_`).

There are many examples where such a feature may be useful.

For example, `Iterable.map`/`Iterable.forEach` may want to pass the index of the item to the callback as a second parameter:

```dart
[].map((value, index) => something);
```

Another example is the optional `child` argument on the `Builder` pattern of Flutter widgets.
Some widgets like `AnimatedBuilder` or `ValueListenableBuilder` takes an optional `child` for performance optimizations like so:

```dart
ValueListenableBuilder(
valueListenable: listenable,
// `child` passed to the function is the value pased to ValueListenableBuilder constructor
builder: (context, value, child) => something,
child: // cached widget
);
```

But some widgets such as `StreamBuilder` currently do not offer such `child` argument – which makes them inconsistent.
Ideally, these widgets should take an optional `child`, but again that is a relatively significant breaking change.

With this proposal, the changes described above would **not** be a breaking change any more.