Don't set "platform library" for .NET Core 3.0 and higher

[dsplaisted]

Don't try to exclude files from the platform library on .NET Core 3.0 and higher, which uses runtime and targeting packs instead

Fixes #3004

To help verify whether this is safe, I looked at the places where MicrosoftNETPlatformLibrary is used:

• It's used by the GenerateDepsFile, GenerateRuntimeConfigurationFiles, and ResolveCopyLocalAssets tasks. These all simply pass it to LockFileExtensions.CreateProjectContext. In that method, it's used as part of the check to determine if the app is framework dependent:

  bool isFrameworkDependent = (platformLibrary != null || runtimeFrameworks?.Any() == true) &&
      (!isSelfContained || string.IsNullOrEmpty(lockFileTarget.RuntimeIdentifier));

  Note that for .NET Core 3.0 and higher, the ResolveFrameworkReferences should add RuntimeFramework items, so the isFrameworkDependent calculation should still work.
• In the created ProjectContext, the GetRuntimeLibraries method excludes assets from the platform library for framework dependent apps.
• The GenerateRuntimeConfigurationFiles task also uses the platform library from the ProjectContext in order to write the runtimeconfig file, but only if there aren't any RuntimeFrameworks.
• The ResolvePackageAssets task excludes assets from the platform library in GetPlatformPackageExclusions. (It also excludes assets from libraries matching names of RuntimeFrameworks, which I believe we should now remove, as those assets will come from runtime packs and won't be in the assets file anyway now).
• The _RestoreCrossgen and PrepforRestoreForComposeStore use the platform library name. These are both part of support for dotnet store, which we are considering dropping, and which will need a lot of work in any case if we want it to work when targeting .NET Core 3