[browser][coreCLR] Assembly.LoadFrom("xxx.dll") doesn't hit external_assembly_probe

In browser/wasm we download DLLs from server during startup. This is done because dotnet API for loading assemblies is synchronous and browser `fetch` is asynchronous. And so we could not fetch assembly from server lazily on-demand (in single thread).

So there is application manifest that contains list of all known assemblies. We install them into linear memory, but we do not place them into virtual file system (VFS). Because that would consume additional memory of the browser tab. We don't really have memory mapping that normal OS has. VFS is bunch of JS objects, which don't live in WASM linear memory.

The normal behavior of `Assembly.LoadFrom("xxx.dll")` is to look up the file on disk and memory map it into dotnet process.
Mono on WASM intercepts LoadFrom via `mono_dl_open` and if the file is already in memory, we would return that.

**On CoreCLR, there is `external_assembly_probe` that we use to load files into memory, but it is not called for `Assembly.LoadFrom`. Should we call `external_assembly_probe` for `Assembly.LoadFrom` ?**

[Xharness](https://github.com/dotnet/xharness/blob/799df8d4c86ff50c83b7a57df9e3691eeab813ec/src/Microsoft.DotNet.XHarness.TestRunners.Xunit/WasmApplicationEntryPoint.cs#L56) on WASM is using that Mono/WASM behavior and possibly other Blazor applications, we don't know.