Make targeting pack test fail if nupkg doesn't exist but should've been built

[dagood]

When adding functionality to skip building targeting packs in servicing builds unless they're being patched (https://github.com/dotnet/core-setup/issues/8735), the tests broke because they assumed the targeting packs would always be built.

The short-term fix was to change the tests to simply pass when the nupkg doesn't exist.

master: dotnet/core-setup#8824
windowsdesktop master: dotnet/windowsdesktop#230
3.0: dotnet/core-setup#8827
3.1: dotnet/core-setup#8828

This could cause the tests to pass even when a nupkg should have been created. It's unlikely this will cause problems (details in 3.0/3.1 PRs above) but in any case, it's a regression in testing coverage that should be closed.

The difficulty here is wiring through the info about whether a package should have been created all the way to the test code. A simple approach would be to put a {nupkgFileName}.intentionallyNotBuilt file in the artifacts dir when a build is skipped, then the tests look for it based on convention.

[NikolaMilosavljevic]

[Triage] @jkoritzinsky is this implemented with SharedFX refactoring or would it be valuable to add it?

[jkoritzinsky]

I think including some sort of check tooling for this might be useful, but it isn't urgent. This was not implemented with the SharedFX refactoring.

[NikolaMilosavljevic]

@ericstj does this test make sense now that we are servicing targeting packs with every release?

[ericstj]

Maybe those tests could be reverted back to the not do this:

The short-term fix was to change the tests to simply pass when the nupkg doesn't exist.