Support for external custom resource-set types seems to be very advanced and possibly never used feature in practice. It makes trimming very complicated and brings large unnecessary dependencies as well as opens doors for potential security problems. The idea would be to add a new feature switch to block setting mediator.UserResourceSet and validate that .resources files require only System.Resources.RuntimeResourceSet and System.Resources.ResourceReader which I suspect all netcore apps use anyway.

Effectively replacing CreateResourceSet with

internal static RuntimeResourceSet CreateResourceSet(Stream store)
{
	// TODO: +Do checking for resource header versions
	return new RuntimeResourceSet(store, permitDeserialization: true);
}

This would have two effects

1. Removing all resources related warnings from illinker because of linker unsafe behaviour
2. Large size savings in refactored code due to fewer dependencies

The feature switch would also help with size trimming work a lot because it would allow propagating the information that we are dealing with RuntimeResourceSet only everywhere. In practice removing, for example, all code in ResourceReader which handles non-_ums code paths (including Unicode encoding dependency, etc).

@eerhardt @vitek-karas