[Components] EventCallback<T> changes the RenderTreeBuilder.AddAttribute(object) behavior

[chucker]

Describe the bug

The introduction of EventCallback<T> in #6351 changes the behavior of RenderTreeBuilder.AddAttribute(object) such that calls that were previously treated as delegates — an onclick attribute, for example — now fall back to a ToString() call.

This breaks code between Blazor 0.8 and 0.9, and doesn't appear to be the intended behavior of the AddAttribute(object) overload. There still exists a case for delegates, but it doesn't seem to be used any more:

// BUG: Action<UIMouseEventArgs> in Blazor 0.8 _was_ a MulticastDelegate
// but EventCallback<UIMouseEventArgs> is not!
else if (value is MulticastDelegate)
{
    Append(RenderTreeFrame.Attribute(sequence, name, value));
}

To Reproduce

Steps to reproduce the behavior:

1. Using this version of ASP.NET Core: 3.0.0-preview3-19153-02
2. Run this code:

        protected override void BuildRenderTree(RenderTreeBuilder builder)
        {
            base.BuildRenderTree(builder);
            builder.OpenElement(0, "MyCustomTag");

            var param = new KeyValuePair<string, object>("onclick", 
                EventCallback.Factory.Create<UIMouseEventArgs>(this, s => { }));

            builder.AddAttribute(2, param.Key, param.Value);
            builder.CloseElement();
        }

Expected behavior

param.Value should be recognized as a delegate.

Actual behavior

RenderTreeBuilder falls back to treating param.Value as an unrecognized object, and calls ToString() on it.

Therefore, in the generated DOM in the browser looks something like:

<button
onclick="Microsoft.AspNetCore.Components.EventCallback`1[[Microsoft.AspNetCore.Components.UIMouseEventArgs,
Microsoft.AspNetCore.Components,
Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60]]">

Additional context

This came up in the BlazorStrap project, and is tracked there as chanan/BlazorStrap#42.

[mkArtakMSFT]

Thanks for contacting us, @chucker.
@SteveSandersonMS was this intentional? Do we plan to do anything here?

[SteveSandersonMS]

I don’t think we expected this to affect anything for other delegate types, but @rynowak has the most context on this change.

[rynowak]

We will need to fix this, it's basic quality of life for using C# to author components. This will come up again when we do splatting as well.

[rynowak]

This was fixed in #10357