Allow subtypes of EventEmitters in @Outputs

[MichaelRFairhurst]

Currently, code such as

class MyEventEmitter<T> extends EventEmitter<T> { ... }

...
   @Output MyEventEmitter<int> intEvents;

will fail.

Per @scheglov, its possible that EventEmitter itself is already a subtype of the required type, which may be simply Stream<T>.

Note as well that we should do this right, tracking where the subtype relationship specifies the type parameters, ie

class MyIntEventEmitter extends EventEmitter<int> { ... }

If this is considerably more work then a new ticket should be made for this edge case.

[MichaelRFairhurst]

Upping the importance of this for two reasons: Firstly, per some discovery showing it comes up a lot. Secondly, when this goes wrong it currently has no fallback behavior and it complains about the $event variables when it can't identify their type.

Also confirmed that Stream is the required type, not EventEmitter.

Therefore the goals are twofold:

1. support subtypes of Stream<T> while allowing for classes to specialized Streams (ie, extends Stream<int>), and
2. use dynamic type when the event type can't be found

[scheglov]

For Stream subclasses support you might want to look at https://github.com/dart-lang/sdk/blob/1ac36f7c3872911b897fc1c61ac90bd9489d650d/pkg/analyzer/lib/src/generated/type_system.dart#L1193 and its use in https://github.com/dart-lang/sdk/blob/3c437f5d9e3b2cefd581d34f08d8ab4484bea608/pkg/analyzer/lib/src/generated/error_verifier.dart#L4220.

[MichaelRFairhurst]

Ah! That is exactly what I was hoping would exist!

[MichaelRFairhurst]

PR #89 merged