Enable peverify-compat mode when SecurityTransparent or APTCA assembly attributes are present

[VSadov]

Same as #22772 + enabling compat mode when SecurityTransparent or APTCA assembly attributes are present

[VSadov]

Closing this.
Due to the interaction of various security related attributes, inferring the demands of a given assembly statically does not seem to be practical.

For example - meaning of of SecurityCritical or APTCA may be altered via

[assembly: SecurityPermission(SecurityAction.RequestMinimum, SkipVerification = true)]     and/or
[assembly: SecurityRules(SecurityRuleSet.Level2, SkipVerificationInFullTrust = true)]

And in a case of a .net module, we cannot even know all the attributes at compile time.

[svick]

@VSadov In that case, would it make sense to be conservative, i.e. enable peverify-compat if one of the attributes is present, even if it might not be actually necessary (because of SkipVerification = true)? Unnecessarily disabling an optimization in fairly rare cases sounds better to me than throwing VerificationException in previously working code.

Or is "If you upgrade to C# 7.2/8.0, your code might start throwing VerificationException" acceptable?

[VSadov]

@svick - there will be a flag to control the behavior (separate PR).

This one was just to explore if we can have heuristics that are triggered by the attributes. Turns out that is not very reliable. It has potential for both false positives and false negatives.

Also it is likely that the user who cares about verification would want errors/warnings when he uses features/patterns that are impossible to emit in verifiable way, but it would be bad to key breaking diagnostics on an unreliable heuristics.
Once we agree that the compiler switch is needed anyways - to be sure to have predictable behavior, it becomes questionable whether attribute based heuristics is useful.