Implement {Try}HashData on asymmetric algorithms

[vcsjones]

An implementation to consider for #66228, if we want to go down this path.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

An implementation to consider for #66228, if we want to go down this path.

Author:	vcsjones
Assignees:	vcsjones
Labels:	area-System.Security
Milestone:	-

[vcsjones]

Mostly unrelated from this PR, but the "overloads" in the test names didn't seem correct to me. Consider this a "rider" pull request. 😄

[vcsjones]

Open task right now is, for my own education and interest, get a JIT dump for TryHashData to see if some level of tiering burns in the is T check.

[vcsjones]

First, a preface: I am by no means experienced with JIT dumps. But I took a stab at looking at a JIT dump of this pattern:

using System;

Console.WriteLine(new FooImpl().Bar());

interface IMarker {}

public abstract class FooBase {
    public virtual int Bar()
    {
        if (this is IMarker)
        {
            Console.WriteLine("marker");
            return 1;
        }
        else
        {
            Console.WriteLine("no marker");
            return 1;
        }
    }
}

public sealed class FooImpl : FooBase, IMarker
{
}

At least on macOS ARM, I don't see the this is IMarker check get elided. It ends up as a helper call to CORINFO_HELP_ISINSTANCEOFINTERFACE.

IN0001: 00000C                    ldr     x1, [fp,#24]
IN0002: 000010                    movz    x0, #0xa600
IN0003: 000014                    movk    x0, #0x80e9 LSL #16
IN0004: 000018                    movk    x0, #2 LSL #32
IN0005: 00001C                    bl      CORINFO_HELP_ISINSTANCEOFINTERFACE
etc

I'm not sure how much we care, but it was a fun exercise.

@bartonjs I am marking this as "ready", but if we want to go back to overrides because we end up with interface checks, or if we can figure out how my testing was wrong, I am happy to adjust.