Enable IL2057;IL2062;IL2096 trimmable warnings

[Tanya-Solyanik]

7006bb4 (and #7290) suppressed trimmable warnings to enable dependency flow. These warnings should be further investigated.

Suggestions from Jeremy and Vitek:

1. Annotate types that are serialized into resx. Introduce a build-time/design-time tool that that parses resx and generates list of types that should be preserved when trimming is on. In runtime ensure that these types are referenced. That might not be sufficient for report designer/winres.exe type of an application, where a resx file is loaded as a file, not as a .resources file which is linked in.
2. Do not put RequiresUnreferencedCode on the internal APIs, otherwise the developer would not be able to handle warning messages. In fact, a more useful messages would explain which types the developer should make "untrimmable" (explicitly referenced). For example, if developer uses an attribute with a string argument which is a type name, Developer should be informed that it's their responsibility to ensure that the named type is not trimmed (is statically discoverable)
3. Example of a good message -https://source.dot.net/#Microsoft.AspNetCore.Http.Extensions/HttpRequestJsonExtensions.cs,22
4. Consider introducing alternative APIs that support trimming
5. In Com2Properties.cs file [return: DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)] could be used if an array of hardcoded types is replaced with a method that enumerated these types

Related to #4649

[vitek-karas]

That might not be sufficient for report designer/winres.exe type of an application, where a resx file is loaded as a file, not as a .resources file which is linked in.

Not all scenarios must support trimming. I think it's very reasonable to not support trimming in designer scenarios. Trimming is applied during publish - designers typically don't act on published apps (at least as far as I understand their behavior).

For example, if developer uses an attribute with a string argument which is a type name, Developer should be informed that it's their responsibility to ensure that the named type is not trimmed (is statically discoverable)

It's possible to add DynamicallyAccessedMembers attribute onto a string parameter - in that case it's understood as a type name. So the trimmer will preserve such type (and the necessary members).

[RussKie]

/cc: @kant2002