Improvements for delegate types (#516)

* Improve support for more types of event handlers

Improves support for for other types of event handlers with eventargs
types derived from UIEventArgs. Additionally fleshes out the set of
event handler types.

This change improves support for using more specific event handler types
like:

```
<button onclick="@Clicked" />

@functions {
    public void Clicked(UIMouseEventArgs e) { ... }
}
```

And:
```
builder.AddAttribute(12, "onkeypressed", KeyPressed);

...

void KeyPressed(UIKeyboardEventArgs e) { ... }

```

In particular what got better is:
- overload resolution for the AddAttribute method
- performance of different cases for AddAttribute

-----

The runtime now treats delegates as one of three types:
- arbitrary delegate: not attached to DOM events, not tracked by
renderer
- UIEventHandler: can attach to DOM events, tracked by renderer, first
class in IHandleEvents
- UIEventHandler-like: can attach to DOM events, tracked by renderer,
requires some special runtime support.

The set of overloads on AddAttribute has been tuned with a few specific
cases in mind.

Lambda expressions in an attribute will be inferred as UIEventHandler
unless the compiler does something more specific. So for instance,
passing a lambda as an attribute value for a component, where the
component doesn't define a matching attribute, will always be inferred
as UIEventHandler.

We now support method-group to delegate conversion for methods that
accept a derived UIEventArgs type. This means you can use a signature
like `void KeyPressed(UIKeyboardEventArgs e)` without any compiler
magic, and this will work in the runtime as long as the event type
produced by the runtime matches.

We also allow user-defined UIEventArgs-derived types. There's a pattern
for this and it requires defining an extension method and delegate type.

The method-group to delegate conversion part required some doing. It
doesn't play well with generics (Action<T> where T : UIEventArgs)
doesn't work at all. Adding more actual overloads (as opposed to
extensions) would cause lambda cases we want to work to be ambiguous.

----

The performance win here is to remove the need for a 'wrapper' delegate
created by the event handler tag helper code. This wrapper is now
created by the runtime, but only *after* we have checked the frame for
changes. This requires more heavy lifting in the runtime, but has the
advantage of producing no-op diffs as often as possible.

You will still get some inefficient behavior if your component uses a
capturing lambda in an event handler, so don't do that.

* Add selenium logs to test output

* Minor feedback

* WIP