Fix source generator issues

[manodasanW]

This addresses a couple issues that came up with respect to our source generator:

• There are scenarios where we generate code making use of unsafe. This can lead to compiler errors that might not be immediately obvious if unsafe isn't enabled and wasn't enabled by a CsWinRT package reference. So now we detect if unsafe isn't enabled and instead produce a diagnostic with a code fix to allow unsafe blocks. This is similar to what the other .NET sources generators do that also generate code using unsafe. Fixes SourceGenerator generates code using unsafe even if EnableUnsafeBlocks aren't enabled #1721
• We were generating code for generic interface instantiations in scenarios we can say for sure aren't WinRT scenarios. Specifically, for .NET custom WinRT type mapping classes, we treated function calls to them as if they were WinRT classes and generated code to make them AOT safe when needed. But given they are not actually WinRT classes like string.Join, we do not need to generate during those scenarios. Addressed by differentiating the check to be for whether it is a WinRT class rather than just a WinRT type.
• Instantiations of generic types defined in the same assembly were not getting code generated for on the vtable lookup table. This was due to the check we put where we said if the type is defined in the current assembly, we will probably be generating an attribute on it so we don't need to put it on the lookup table. But that isn't true if it is a generic class implementing generic interfaces. Addressing by making that check more accurate. Fixes AOT generator ignores generic classes inheriting from generic types #1724

[manodasanW]

Validated with a couple repro scenarios that they behave as expected with the fix.