[Static web assets] Fixes issues we discovered while integrating the static web assets improvements on to the ASP.NET Core repo

[javiercn]

Description

As part of integrating the changes we did to static web assets into the ASP.NET Core repo, we ran into some issues and this PR Contains the fixes to them.

• Filter doc XML files from blazor static web assets
• Fallback to Identity metadata when we try to match project references
  • This is not technically necessary because regular projects have the right metadata, however, ASP.NET Core uses some
    special project types and its easy/cheap for us to be more lenient here and fallback.
• Correct empty entry for manifest pattern on generation
  • The dotnet.js manifest file was not being passed on to GenerateBlazorBootJson manifest.
• When generating the manifest we use for development we were including empty entries "" as well as the base path for assets
  in the current project, which is not necessary.
• Only include discovery patterns when the folder exists on disk
  • For example, avoid creating a pattern when the wwwroot folder doesn't exist, since we can't map a non existing folder at runtime.
• Correctly compute the asset path for assets that are copied to the output folder.

The PR is divided in three commits:

• The first commit is the important one and contains the fixes mentioned above.
• The second commit contains test improvements we've done to ensure we are solid.
• The third commit updates the test baselines for the different builds we perform.

Customer Impact

Customers won't be able to load Blazor apps unless they switch to the previous Static Web Assets implementation (we included a flag for this) however, we want to make sure this is the default experience in Preview7 to ensure that we uncover as many issues as we can, since these improvements are the foundation for many of the new features we are building

Regression?

• Yes
• No

6.0 Preview6

Risk

• High
• Medium
• Low

The changes are complex, however we put a fallback mechanism in place to force the older implementation to be used. In case a scenario doesn't work for a user, they can resort to the preview6 implementation setting a value on their csproj file.

Verification

• Manual (required)
• Automated

Manual verification is problematic and limited due to the fact that there is a build time component and a runtime component and that they live on different repositories.

I've been able to use a freshly built "dev sdk" to build one of the samples and i've used the runtime changes (paired with this ones) to run the project and run the published project.

Packaging changes reviewed?

• Yes
• No
• N/A

[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.

[mkArtakMSFT]

Approved by tactics.