Reenable taghelpers glob tests

[HaoK]

There are two tests skipped on helix due to the move to running from the publish directory from #29449

• IdentityUIScriptsTest.IdentityUI_ScriptTags_FallbackSourceContent_Matches_CDNContent
• HtmlGenerationWebSite_GeneratesExpectedResultsNotReadyForHelix
• HtmlGenerationWebSite_GenerateEncodedResultsNotReadyForHelix
• TagHelpersTest.CanRenderViewsWithTagHelpersNotReadyForHelix
• Also revert:

      public async Task CompilationFailuresFromViewImportsAreListed()
          var expectedCompilationContent = "public class Views_ErrorFromViewImports_Index : "

[dougbu]

Made the description a checklist in case we handle some of these individually. Also added IdentityUI_ScriptTags_FallbackSourceContent_Matches_CDNContent to the list.

Good news is [SkipOnHelix(...)] continues to be used mostly with a list of queues to avoid. Bad news is the tests in this issue are not run at all because $(SKipHelixReadyTest) operates at the project level, skipping all tests that would normally build a Helix payload.

[dougbu]

From #30703 discussion:

One solution would be to add a new property that allows us to run only [SkipOnHelix(...)] tests on the build agents.

Another (ugly) option would be to continue not running those tests at all. Might as well remove them or treat them as manual-only tests☹️

My first suggestion isn't complete because we still want to run tests in projects that do not build Helix payloads. This issue is about finding a way to run the (fortunately small) subset of tests from projects that do build Helix payloads but the particular test won't execute in any Helix queue. That's in addition to running the tests we currently run on the build agents.

[HaoK]

Well this issue is specifically only about the tests I broke as part of helixification work in the unification of publish/functional tests, IdentityUIScriptsTest.IdentityUI_ScriptTags_FallbackSourceContent_Matches_CDNContent is unlikely to be related to that so it probably won't be resolved by this bug.

[HaoK]

I think what you want is another meta issue that is about what to do about specific tests that are skipped on helix (for all queues), I would assume each of those needs to be tracked by its own issue if its something that needs to be followed up on, there's not going to be a general catch all soln for all the different tests that don't work on helix in some way

[dougbu]

there's not going to be a general catch all soln for all the different tests that don't work on helix in some way

Why not❔ My solution would work though it's likely pretty inefficient.

Another catch-all option would be to split the individual tests into separate non-Helix-ready projects. Best case would be a single project, albeit w/ lots of dependencies.

[HaoK]

I mean sure I guess that's possible, but it seems more worthwhile to just fix the tests that we really care about, and the rest just fall into the same bucket as test failures/quarantined tests (debt). There really shouldn't be many tests in this bucket anyways, the plan generally for these to be skipped and have issues filed for them, as its basically follow up work from the helixifaction.