Add mvid and metadata token API to S.R.TypeExtensions

[nguerrera]

NOTE: Marking as WIP because build and tests will fail without dotnet/coreclr#1781 and #3861

This adds ModuleExtensions and MemberInfoExtensions to the the System.Reflection.TypeExtensions library that provides extension methods to bridge reflection gaps. (It already has PropertyInfoExtensions, etc. etc.)

• Classic MemberInfo.MetadataToken is re-surfaced as MemberInfo.TryGetMetadataToken(out int token).
• Class Module.ModuleVersionId is re-surfaced as Module.TryGetModuleVersionId(out Guid mvid)

The TryGet pattern is used to draw attention to the fact these will not be supported everywhere (.NET Native will simply return false).

Update: Changed to HasXxx and GetXxx from TryGet after API review feedback.

Other options such as nullables or using default(T) for failure were considered, but one thing that folks do with these is compare the return value from one instance to another which would give silent false positives. I think the scenarios for using these are limited enough for the more cumbersome signature.

Fix #2375

cc @weshaggard @delmyers

[weshaggard]

Isn't this supposed to be an extension method? I don't see the this keyword.

[nguerrera]

Yes, it didn't affect testing because everything goes through the reference assembly.

I actually left off the 'this' in implementation for things that have an exact instance counterpart in mscorlib (otherwise code looks like infinite recursion, but that doesn't apply here, and in fact on desktop you reference the impl and need to see this new method as an extension.

Will fix.

[nguerrera]

Changed to account for API review feedback. @KrzysztofCwalina PTAL.

[nguerrera]

(This will still fail CI as the CoreCLR package needs to be updated.)

[KrzysztofCwalina]

looks good.

[stephentoub]

@dotnet-bot test this please

[nguerrera]

I've had to update the test-runtime to include Module.ModuleVersionId, which triggered #4040.