Static Web Assets - Bundle in with projects own StaticWebAssets

### Is your feature request related to a problem? Please describe.

There are multiple related issues but I wanted to create a specific request here. The related issues are:
- https://github.com/dotnet/aspnetcore/issues/20763
- https://github.com/dotnet/aspnetcore/issues/20567

As described by the linked issues, the basic problem is:
Given a host project (H), that references two different blazor wasm projects (A & B)
If H references A and B with `ReferenceOutputAssembly` = false, and A or B have package references to nuget packages containing static assets - those static assets won't be available on the host at runtime, only A's and B's direct content / static assets will be served - which essentially breaks those apps as only partial content can be served, and you only know about this through running the app and waiting for the error to be discovered.

Looking at `H.StaticWebAssets.xml` that is generated during a development build of the host project, when `ReferenceOutputAssembly` = false for those project references (A and B) - there are no longer entries for the dependencies of A & B so those static assets are now no longer "known" to the solution / msbuild, and therefore, they are also not included by `dotnet publish` when copying assets to the hosts `wwwroot` directory, or available at runtime. There is no build warning or error when this happens.

In addition to this a related issue which my proposal will cover:

If projects A and B both reference different versions _of the same package_, i.e "A-DEPv1 and B-DEPv2 - the current result will be a conflict, as they both want their dependencies assets to be placed under _content/DEP - but we have two different sets of files here - boom!

## Solution I'd like to see

However I'd like for there to be a way, optionally, for a project to also say: actually... static assets from my package x, should be treated as if they were "Mine" - i.e resolved relative to my own static assets base path which is unique to me. Other projects in the solution could also optionally do the same, allowing each app to have its static assets from any dependencies, isolated from one another within its own static assets base path, rather than all placed under a shared _content/ location. This could be used both the issues raised.

Hopefully this will be clearer with this example:

If project A currently has:

```
spa/A



```

I'd like to see something along the lines of:

```
spa/A



```

Note I just added "CopyStaticAssets="true" to the package reference. This would be some hint that would cause that packages static assets to be copied / resolvable from, a path now relative to the projects StaticWebAssetBasePath within the wwwroot directory, on publish, and likewise during development, e.g:

Project A --> Index.html
```

```

Without this feature being opted into, the path would continue to be same as today rather than the above, e.g from the shared _content/ directory that is not private to this project's assets:

```

```

This would solve the above two issues because:

1. When H references project A or B with `ReferenceOutputAssembly` = false, project A and B's own `StaticWebAssetBasePath` are already being mapped during development via `H.StaticAssets.xml` file in H's output directory so can be served up by the host. So this means if the only change was to have this feature additionally copy the assets on build, from the package references to this path, then H can serve them up already without any changes. In reality if you can do some fancy path mapping / IFileProvider stuff at build time, to avoid the physical copying at development time, and defer it until a dotnet publish, that would also be great. Here is an example of a current `H.StaticAssets.xml`:

```

```

and as the same directory is already being copied by `dotnet publish` - there would be no changes needed to that process, either, or any MSBuild changes in terms of making it consider additional packages that it currently ignores when `ReferenceOutputAssembly` = false.

2. It means multiple client projects can each include static assets that together may be from different versions of the same package, without conflictsing with each other, by allowing assets to be kept private / discreet to the projects own StaticWebAssets path, which already must be unique within a solution.

I think this could be something that can be added without breaking changes to existing projects, through some kind of optional msbuild property / attribute etc.