Bring back direct dependencies on System.Runtime.CompilerServices.Unsafe for other tfms than net7.0

[ViktorHofer]

Fixes #67380

Add dependency on Unsafe package

With the removal of the Unsafe package, a few projects which
previously had a direct dependency on the latest version of Unsafe
(6.0.0) regressed as they depend on the transitive Unsafe dependency of i.e.
System.Memory which is a very old version (4.5.*).

Fixing those projects to declare the direct dependency again.

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

[ViktorHofer]

cc @tarekgh @Wraith2

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #67380

Add dependency on Unsafe package

With the removal of the Unsafe package, a few projects which
previously had a direct dependency on the latest version of Unsafe
(6.0.0) regressed as they depend on the transitive Unsafe dependency of i.e.
System.Memory which is a very old version (4.5.*).

Fixing those projects to declare the direct dependency again.

Add infrastructure to use the latest Unsafe ver

Whenever Unsafe would be consumed as a transitive dependency of
System.Memory, System.Threading.Tasks.Extensions or
Microsoft.Bcl.AsyncInterfaces, a very old version of it would be chosen.

Make sure that when that's the case, to upgrade the version to the
latest available unsafe package.

Author:	ViktorHofer
Assignees:	ViktorHofer
Labels:	area-Infrastructure-libraries
Milestone:	7.0.0

[eerhardt]

Don't we need this on net6.0?

[ViktorHofer]

The net6.0 tfm doesn't use Unsafe:

[eerhardt]

It uses System.Memory though...

Or is this the case where the infrastructure will kick in and add the PrivateAssets PackageReference above?

[ViktorHofer]

Correct but projects should only reference direct dependencies, transitives are brought along via the project.assets.json file and the ResolvePackageAssets task (NuGet).

[ViktorHofer]

Also in this case we talk about the System.Memory 6.0.0.0 assembly from the shared framework and not the 4.5.* version from the package so the Unsafe assembly used is already the latest one from the shared framework (6.0.0.0).

[ViktorHofer]

I added two more commits:

• Commit 3 cleans up a few project files where references weren't needed anymore and a few style cleanups.
• Commit 4 undoes Commit 2 as there is actually no reason to use the latest Unsafe package when being referenced transitively.

[ViktorHofer]

Merging the PR in now. We could consider always referencing the unsafe package when ie the System.Memory package is referenced, even if it isn't a direct dependency but that would be a separate change and I'm not sure it would be the right thing to do.

[ericstj]

I think you might be able to get away with omitting the PackageReference if the asset is targeting net6.0. Since we won't ever ship a newer version than the one in net6.0 and the version used on net6.0 is also kept up to date by the framework where it is inbox. Probably more trouble to special case that than it's worth, but that was what I thought folks were asking in the related issue.

[ViktorHofer]

That's a valid response. The corner case, when customers use the latest available patched package but aren't using the latest patched corrrsponding shared framework, isn't handled then though.

Packages provide us the abiluty to reach customers faster as it's more common that packages are updated to the latest than that shared frameworks are updated because of a recent patch. Admittedly, Visual Studio does help update shared frameworks.