[release/3.1] Update dependencies from EFCore

[wtgodbe]

After Extensions removed the Mono.WebAssembly.Interop package yesterday, Maestro silently failed to update our dependencies from EFCore, because we still listed a dependency on that package despite it not being produced (thanks @riarenas for helping figure this out). I deleted that package from our version files & ran darc update-dependencies locally. Here's the issue tracking making these types of failures less difficult to notice/track down: dotnet/arcade#1387

CC @dougbu @JunTaoLuo - after this I can validate #19161 (since this updates System.IO.Pipelines to 4.7.1)

[wtgodbe]

/Users/runner/runners/2.164.8/work/1/s/src/Components/Blazor/testassets/HostedInAspNet.Server/HostedInAspNet.Server.csproj : warning NU1602: Microsoft.AspNetCore.Blazor does not provide an inclusive lower bound for dependency Mono.WebAssembly.Interop. An approximate best match of Mono.WebAssembly.Interop 0.5.0 was resolved.

Services/WebAssemblyJSRuntime.cs(9,50): error CS0012: The type 'JSInProcessRuntimeBase' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.JSInterop, Version=0.5.0.0, Culture=neutral, PublicKeyToken=null'. [/Users/runner/runners/2.164.8/work/1/s/src/Components/Blazor/Blazor/src/Microsoft.AspNetCore.Blazor.csproj]

@pranavkm should I instead have pinned the dependency on Mono.WebAssembly.Interop?

[wtgodbe]

We still use Mono.WebAssembly.Interop, so I put it in the manual section of versions.props (effectively pinning it): https://github.com/dotnet/aspnetcore/pull/19201/files#diff-8b8f08ffbf7b863fb3700c1718eeb4cbR207