Add support for loading satellite assemblies

[pranavkm]

Fixes #17016

---

How this works:

• We want to eagerly fetch satellite assemblies for all cultures.
• Emscripten sets up the app's culture based on the user's language preference navigator.languages
• To calculate the closure of assemblies to load, we have to walk the graph of parent cultures. This some non-trivial jumps (e.g. parent of mn-MN is mn-Cyrl, so it's not as trivial as trimming values. .NET already has the ability to do this.
• To this effect, we defer loading satellite assemblies until .NET code begins to execute - in this case EntryPointInvoker. .NET calculates the closure, sends it off to JS which knows available cultures from blazor.boot.json.
• Once the app loads, we can no longer use mono_wasm_load_assembly - it has no effect. However, we are able to load assemblies using Assembly.Load(byte[]). JS sends bytes to .NET which it then loads.
• We let Program.MainAsync execute. This affords the developer to change the culture based on some ambient state such as localStorage or query.
• If the culture is different, as part of WebAssemblyHost.RunAsync, Blazor fetches a new set of satellite assemblies.

Doing this in two part is nice in that in the default case, the application has access to localized resources as part of MainAsync just as with any .NET application. It does mean some users may have to download an additional set of assemblies.

One edge case that falls part is if the application uses IStringLocalizer as part of MainAsync and changes the culture. e.g.

CultureInfo.DefaultThreadCurrentCulture = GetCultureFromPath(..);
ApplicationMessage =  Host.Services.GetRequiredService<IStringLocalizer<Messages>>()["AppMessage"];

The default implementation caches lookups, so newly loaded assemblies do not show up. Things work fine if you use IStringLocalizer in an ordinary way.

[pranavkm]

I had to account for these in path manipulation. Removed since this isn't used any more.

[pranavkm]

Slight reshuffling to make it easier to view the binary logs

[pranavkm]

Some of this code was duplicated in the file, possibly a bad merge.

[pranavkm]

I tried your suggestion and it looks like we need to target es2019 to use it. Are there downsides to doing that?

[SteveSandersonMS]

Browser support for .flat looks reasonable, however it's not like we're saving ourselves dozens of lines of code here.

Your original implementation looks totally fine to me, too!

[SteveSandersonMS]

Is the issue that Windows has a different opinion than Mac/Linux for this culture?

If so it seems reasonable just not to have this particular test case. Is there any other test case with nontrivial rules (not of the form { "X-Y-Z", "X-Y", "X" })?

[pranavkm]

Hmm, doesn't look like there are any non-trivial cases in Linux (haven't tested OSX). I wonder if the Linux implementation just uses the trivial fallback behavior.