As specified, type inference infers no constraint for Null <: Future<T>

The local inference informal specification (https://github.com/dart-lang/sdk/pull/29371) says:

- `P` is a subtype match for `FutureOr` with respect to `L` under constraints
`C`:
- If `P` is a subtype match for `Future` with respect to `L` under
constraints `C`.
- Or `P` is not a subtype match for `Future` with respect to `L` under
constraints `C`
- And `P` is a subtype match for `Q` with respect to `L` under constraints
`C`

The analyzer behavior is slightly different in the case where `P` is a subtype match for *both* `Future` and `Q`. (This happens, for instance, if `P` is `Null`). In that case, if the attempt to match `P` against `Future` generates zero constraints, but the attempt to match `P` against `Q` generates constraints, then the constraints from matching `P` against `Q` are propagated.

This has a user visible effect in the analyzer. Consider the code:
```
void test(Future f) async {
var t = f.then((int x) {});
(await t).foo();
}
```

The analyzer attempts to infer the type argument for `then` by matching `Null <: Future`. This causes the type constraint `Null <: T` to be generated, therefore `t` has type `Future`, and `(await t).foo()` produces an error. If I change the analyzer to follow the informal specification, it infers a type of `Future` for `t`, and no error is issued. Issuing an error seems like a better behavior here.

(Note that the common front end's behavior is different still: it infers a type of `dynamic` for `t`, due to dart-lang/sdk#33044.)

@leafpetersen @jmesserly what do you think?

Start by reading the linked local inference informal specification and the `FutureOr` example in this issue. Compare its stated constraint propagation with the analyzer and common front end behavior described here; done requires a decision on the intended behavior and corresponding specification or implementation changes.

Written by the indexing model from the issue text.