[blazor] Use JSImport for loading satellite assemblies

[pavelsavara]

Motivation

• The current getSatelliteAssemblies is implemented using legacy/obsolete JS interop.
• legacy interop has problems with multi-threading and uses unsupported API.
• legacy interop is not CSP compliant

Contributes to #37787

Description

• use new generated JavaScript interop with [JSImport]
• drops unit test with mocked IJSUnmarshalledRuntime as that is no longer a dependency.
  • Also logically the JS code is part of the component, not a "dependency"

[maraf]

LGTM 👍

[MackinnonBuck]

I agree that it's fine to remove these tests since they were tied to the old implementation of LoadCurrentCultureResourcesAsync().

Thankfully, it looks like this was one of the only cases where we were mocking IJSUnmarshalledRuntime for test purposes, so I think it should be unlikely that switching to the new JSImport/JSExport interop model will force us to remove a bunch of similar tests in the future.

The one exception to this is WebAssemblyHostBuilder, which relies heavily on IJSUnmarshalledRuntime. Tests currently use TestJSUnmarshalledRuntime to mock JS interop functionality. I would imagine that in this case, we could create an IWebAssemblyHostInterop interface to provide strongly-typed interop, and we could have a "test" interop class along with the "real" one whose implementation invokes the static [JSImport] methods. The same pattern could be applied in other cases, if they arise.

This isn't really a PR suggestion, just some ideas about the future.