[Static Web Assets] Reworks the protocol for getting referenced assets and brings back backwards compatibility

[javiercn]

Static web assets cleanups

Goals

• Bring back back-compat with earlier project types.
• Avoid reading dependent projects static web asset manifests multiple times.
• Allow dependent projects to specify how the referencing project should call
  into them to get the list of static web asset items.

Other work/cleanups

• Make publish respect PreserveNewest.
• Define standard targets where features can attach themselves to generate
  their assets.

Details

In the initial implementation of static web assets V2, we generated a manifest
and asked every referenced project to give us their manifest. This worked but it
incurred in the additional cost of having to read each referenced project manifest
every time we had to compute the manifest for a given project.

In addition to that, it was costly/impossible to support backwards compatibility with previous versions of static web assets, since they use different targets and work in a very different way.

Finally, the old implementation relied on the old project knowing all the details about referenced projects to compute the list of assets, which added complexity to the implementation.

The changes in this PR bring the implementation closer to the original implementation and make it more performant, backwards compatible and simpler.

Static web assets with referenced projects works as follows:

• Gather referenced projects configuration.
• Call referenced projects during build to gather their static web assets
  based on the configuration they gave us.
• Call referenced projects during publish to gather their static web assets
  based on the configuration they gave us.

The initial step is to call GetStaticWebAssetsProjectConfiguration on all projects. This step defines how the remaining steps work by returning an item group that includes the version, the source, the targets and properties to call to get the static web assets for the project during build and publish.

Static web assets V2 defines a standard target GetCurrentProjectBuildStaticWebAssetItems that it calls when no other target has been defined. Projects can change this by setting StaticWebAssetsGetBuildAssetsTargets

A similar thing happens for publish assets, we will call ComputeReferencedStaticWebAssetsPublishManifest;GetCurrentProjectPublishStaticWebAssetItems by default to make sure that the publish asset manifest is generated and retrieve the assets afterwards. Each project can change this by setting StaticWebAssetsGetPublishAssetsTargets.

In addition to that, there are properties that projects can configure to define how we should retrieve their assets:

• StaticWebAssetsAdditionalBuildProperties
• StaticWebAssetsAdditionalBuildPropertiesToRemove
• StaticWebAssetsAdditionalPublishProperties
• StaticWebAssetsAdditionalPublishPropertiesToRemove

These properties are mostly for our internal use and enable us to adapt how static web assets work in different environments, like blazor webassembly or blazor desktop, without burdening those projects with unnecessary details.

This functionality is used also by older projects to bring forward compatibility with the new version of static web assets.

The 6.0 SDK forks static web assets and blazor based on whether the user is targeting 6.0 or earlier, we do this to avoid breaking backwards compatibility with previous versions given the amount of changes we've made to how static web assets work.

If a project targets net6.0 or higher it will load static web assets v2, otherwise, it will load v1, which live in different targets files.

We've updated the V1 SDK file to include targets to bring forward compatibility with static web assets V2.

V1 static web assets define a GetStaticWebAssetsProjectConfiguration target that returns the configuration to use for retrieving the assets. The only important element they return is GetCurrentProjectStaticWebAssetsV2 for retrieving the static web asssets during build.

V1 static web assets projects don't define different assets during publish, so they don't return publish specific static web assets targets as part of their configuration.

Static web assets v1, scoped css v1, and blazor webassembly 5.0, attach to GetCurrentProjectStaticWebAssetsV2 and update the assets properties to adapt them to static web assets v2.

Finally, by calling the referenced projects for their assets, we simplify how the assets are computed when the assets are being referenced by another project.

Other work details

Make publish respect PreserveNewest

This was missing and its obvious, we were just copying the assets to the publish output folder, we now split them by PreserveNewest or Always and do the appropriate thing.

Define standard targets for generating static web assets

Assets can do work at two points:

• If the feature needs to do work to compute the list of static web assets to add, it can do so during Resolve(Publish)StaticWebAssetInputs.
• If the feature does not need to do work to compute the list of static web assets to add, it can declare the assets ahead of time during Resolve(Publish)StaticWebAssetInputs and attach to GenerateComputed(Build|Publish)StaticWebAssets to generate the assets when they are needed.

This makes it easier to adapt when the pipeline targets run in different environments (Webassembly, Maui) without them requiring intimate knowledge of every static web asset feature.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[javiercn]

This is ready for review, the main commits to review are: d9244e4
5bb7e6c

There is a commit that adds tests for all scenarios we care about.

I've put all the generated baselines into their own commit since I've also been doing fixes. The additional tests are also on their own commit, and you can check the associated baseline if you want to see if we are generating the right results.

[javiercn]

Only test failing is unrelated I think

[pranavkm]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pranavkm]

Changes look good. Some questions about test coverage

[javiercn]

dotnet/aspnetcore#35143