Respect the new UnconditionalSuppressMessageAttribute

[eerhardt]

When code wants to suppress a linker warning, for example when the author is certain it is safe, they can add an UnconditionalSuppressMessageAttribute. We should support this new attribute in the linker.

See dotnet/runtime#35339 for the discussion.

[vitek-karas]

There are several aspects of this which can be done in stages:

• Basic support of the attribute on a method - suppresses specified warning inside the method's body.
• Implement support for MessageId - adds the ability to direct the suppression to a specific symbol in the method's body. For example if the linker raises a warning due to a call to Type.GetField then it should be possible to direct the suppression to just that by specifying MessageId with a value of GetField (or maybe System.Type.GetField, or so on - needs a detailed design)
• Support the attribute on more scopes - type, module, assembly and so on. This will be performance sensitive work
• Support targeting the attribute - that is support for the Scope and Target properties. Note that this requires a parser of the string in the Target property. We need this to be aligned with the same functionality in roslyn, both the parser and the semantics. The parser for the Target property can be found here.

Performance considerations: When a warning is suppressed it should be fast - linker should not spend my time finding and suppressing the warning. This is expected to be a relatively common case (likely used inside our frameworks so all apps are affected). This means that finding and matching the suppression attributes must be fast and when a warning is suppressed linker should not spend any time computing the details of the warning (specifically constructing the warning message).

[vitek-karas]

/cc @sbomer - the Target property processing is similar problem to the target of the DynamicDependnecyAttribute in #1148. If we decide to use the same format we should share the implementation of the parser and the semantics of looking it up in the cecil OM.

[MichalStrehovsky]

the Target property processing is similar problem to the target of the DynamicDependnecyAttribute in #1148

Note that the format of the Target for this attribute is already invented. UnconditionalSuppressMessageAttribute is supposed to work the same way as SuppressMessageAttribute and that one already defines how Target is supposed to look like.

[MichalStrehovsky]

We might be able to steal the parser for Target from Roslyn. Roslyn team typically spends a lot of time thinking about corner cases, so it might be beneficial to at least look at it, if not fork it into our repo.

[sbomer]

@eerhardt pointed me to some folks who have more context on the Target - it apparently supports the format documented at https://github.com/dotnet/csharplang/blob/master/spec/documentation-comments.md#id-string-format, as well as a legacy FxCop format for back-compat.

[vitek-karas]

This should be done with #1185 and #1232. It's a not full support for all special cases, but it should be enough for the current needs.