Opaque warnings for unsupported features without managed callers

By design, turning on startup hook support produces a warning. However, the warning shown by default is not helpful.

~~First, it is collapsed:~~ (fixed by https://github.com/mono/linker/pull/2087)
```
dotnet publish -r linux-x64 -p:PublishTrimmed=true -p:StartupHookSupport=true
```
```
...System.Private.CoreLib.dll : warning IL2104: Assembly 'System.Private.CoreLib' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries
```

~~If you uncollapse it,~~ the warning mentions implementation details of the startup hook:
```
dotnet publish -r linux-x64 -p:PublishTrimmed=true -p:StartupHookSupport=true -p:TrimmerSingleWarn=false
```
```
ILLink : Trim analysis warning IL2026: System.StartupHookProvider.ProcessStartupHooks(): Using method 'System.StartupHookProvider.CallStartupHook(StartupHookProvider.StartupHookNameOrPath)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. The StartupHookSupport feature switch has been enabled for this app which is being trimmed. Startup hook code is not observable by the trimmer and so required assemblies, types and members may be removed.
```

Only the last part is useful to the app developer. Note that there is a dependency from the XML descriptor -> ProcessStartupHook -> [RUC] CallStartupHook, and the warning is produced for the call to CallStartupHook.

I believe we need a way to mark some APIs such that they:
- produce warnings that "blame" the feature switch settings, even if they are never called by any other methods (only rooted due to the feature setting)
- do not look like they are warning about implementation details of corelib
- ~~don't get collapsed by default~~

For startup hook, I think it should only say "The StartupHookSupport feature switch has been enabled for this app which is being trimmed. Startup hook code is not observable by the trimmer and so required assemblies, types and members may be removed."

Startup hooks happen to not have public APIs, but the native hosting APIs will have a similar problem, and they do have public UnmanagedCallersOnly APIs. The current approach will show warnings like "public API calls internal method with RequiresUnreferencedCode" - it would be better not to mention the internal APIs.

@LakshanF