Enhance NestedTypes in DynamicallyAccessedMemberTypes

[LakshanF]

We don't do much for nested type options in DynamicallyAccessedMemberTypes, forcing the much broader scope All to be used if we want to preserve members inside nested types. This fix is to keep all the members for nested types.

This impacts EventSource since the type is tagged currently with All and there is a related discussion around size. Unfortunately, EventSource needs to preserve its members as well and there does not seem to be much size saving on EventSource with this change.

Fixes #1174

[sbomer]

Should this really keep everything on the nested types? I would not expect PublicNestedTypes to recursively keep private nested types for example.

[LakshanF]

I was primarily going with the discussion on the issue for the fix from @MichalStrehovsky and the view that there are not wide usage of DAM with NestedTypes in the library

I looked into this change since I was curious if this change would have an impact on the library size due to EventSource proliferations in our library but the size wins are minimal since we need to keep most of parent type members. But created the PR since the consensus in the issue was to fix it.

The trimmer is not able to reason on what is needed for internal types that are decorated with DAM in the library mode since the programming paradigm relies on reflection in application runtime to enable the event source. I think the solution is for custom library source code such as NetEventSource to be refactored to use only what is needed instead of the current model. The runtime issue tracks this but that work might not happen in this release.

[vitek-karas]

Assuming we agree on the behavior (as per the discussion on the issue) the change looks good.
This should be followed by changing the intrinsic behavior of GetNestedType which currently only propagates the All annotation to the return value if the source type was annotated with All. With this change, it can now propagate All always. In fact we may want to change the runtime and add the annotation on the return value directly.

[MichalStrehovsky]

Looks good modulo Vitek's comment about the GetNestedType intrinsic.

Sven is right that we might be able to not mark non-public nested types in the deeper levels, but I'm not sure if it will result in savings in practice and it looks like it would complicate the implementation quite a bit.

class Foo
{
    public class PublicNestedAndReflected
    {
        protected class ProtectedNestedButNotReflected { }
    }
}

If we ask for all public nested types on Foo, we might be able to get rid of ProtectedNestedButNotReflected. But I think it's very unlikely that a fully-preserved PublicNestedType would have no references to ProtectedNestedButNotReflected (not many other classes have access to this nested class since it's not public - chances are pretty high we would end up keeping it anyway).

[tlakollo]

Nit: We should delete these comments in our testing given that now the link will mark more than the declaration