Improve error message for the case when Crossgen2 package is not present

[AntonLapounov]

Improve the error message for the scenario described in #20701 (_crossgen2Tool.PackagePath is not null, but an empty string). The current error message:

NETSDK1095: Optimizing assemblies for performance is not supported for the selected target platform or architecture. Please verify you are using a supported runtime identifier, or set the PublishReadyToRun property to false.

The new error message (it has to cover other scenarios as well):

NETSDK1094: Unable to optimize assemblies for performance: a valid runtime package was not found. Either set the PublishReadyToRun property to false, or use a supported runtime identifier when publishing. When targeting .NET 6 or higher, make sure to restore packages with the PublishReadyToRun property set to true.

The added sentence is in bold. We may also hit this error with .NET 5 if PublishReadyToRunUseCrossgen2 is set to true; however, it is a rare scenario and I did not want to make the error message hard to read.

@dotnet/crossgen-contrib

[trylek]

Looks great, thanks for improving the error message! Would there also be a chance (perhaps in a follow-up change) to make SDK report something actionable when Crossgen2 fails with an error when compiling the assembly? From what I recall from last year when I was switching over framework assemblies to be built using Crossgen2, it was pretty tricky to get to the actual underlying Crossgen2 error and SDK just reported this generic message.

[AntonLapounov]

Failures are caused by an infra issue: #24303 (comment).

[AntonLapounov]

make SDK report something actionable when Crossgen2 fails with an error when compiling the assembly

Could you please describe the scenario where diagnostics is lacking? Note that I closed the issue you opened a year ago, because I could not reproduce it: #15466 (comment). Feel free to reactivate it and provide more details.

[trylek]

Thanks for reminding me, I'll retest this when I have a chance, it's certainly possible that the issue has been fixed since.

[AntonLapounov]

@TanayParikh I am still hitting the infra issue below in this PR. Do you know what is going on?

SENDHELIXJOB(0,0): error : (NETCORE_ENGINEERING_TELEMETRY=Build) Helix queue Windows.Server.Amd64.VS2019.Pre.Open is slated for removal on 2022-03-31. Please discontinue usage. Contact dnceng for questions / concerns

[TanayParikh]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[TanayParikh]

@TanayParikh I am still hitting the infra issue below in this PR. Do you know what is going on?

SENDHELIXJOB(0,0): error : (NETCORE_ENGINEERING_TELEMETRY=Build) Helix queue Windows.Server.Amd64.VS2019.Pre.Open is slated for removal on 2022-03-31. Please discontinue usage. Contact dnceng for questions / concerns

https://dev.azure.com/dnceng/public/_build?definitionId=136&_a=summary the pipeline is passing again so doing an azp run should create a new merge commit to run the CI against. Hopefully that resolves the deprecated Windows.Server.Amd64.VS2019.Pre.Open queue issue.

[AntonLapounov]

@TanayParikh Thank you for the help!