Annotate ControlPoint and Mod for AOT trimming support

[smoogipoo]

I have a native AOT compilation project here: https://github.com/smoogipoo/osu-native-diffcalc It compiles the most minimal types from osu+osu-framework+osuTK into a project that can be used to perform difficulty calculation with.

In it, I've had to add a few workarounds for these types which use Activator.CreateInstance() down various paths: https://github.com/smoogipoo/osu-native-diffcalc/blob/8fb300329425e52aa078b78728ba802bb8124345/Sources/osu.Game.Native.Desktop/Program.cs#L25-L71

This change should remove the need for these workarounds with very little code-wise overhead from the game itself. This is probably good practice in general though I'm not sure when we'll/if ever move towards trimming more aggressively in production.

Here's a test app:

using System.Diagnostics.CodeAnalysis;

new X().Clone().Print();
new Y().Clone().Print();

[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]
public class X
{
    public virtual void Print()
    {
        Console.WriteLine("hello from x!");
    }

    public X Clone() => (X)Activator.CreateInstance(GetType())!;
}

public class Y : X
{
    public override void Print()
    {
        Console.WriteLine("hello from y!");
    }
}

In .csproj:

<PublishAot>true</PublishAot>
<PublishTrimmed>true</PublishTrimmed>

[bdach]

Have you tested that this is enough, on the real thing, rather than on the example in the OP? On a quick look [DynamicallyAccessedMembers] has Inherited = false specified so I am not immediately confident that it will fully eliminate your workaround.

[smoogipoo]

I admit I initially didn't, because it's kinda annoying to, which is why I did it in a separate example.

It does look to be working in practice though, with one caveat - I missed that LegacyControlPointInfo isn't a ControlPoint (naming... >_<) Will fix in next commit.

[smoogipoo]

Fyi, I think that this part of the documentation is the most relevant: https://github.com/dotnet/runtime/blob/257e76dfe64cb5b347aba7bc5a31a50c3c8cc106/src/libraries/System.Private.CoreLib/src/System/Diagnostics/CodeAnalysis/DynamicallyAccessedMembersAttribute.cs#L19-L21

I also noticed Inherited = false and questioned this behaviour, and had to verify myself. I also explored the alternative of using System.Diagnostics.CodeAnalysis.DynamicDependencyAttribute but that one does not work for inherited types.