[Wasm] Add support for baseUrl and mainScriptPath

[jeromelaban]

This change allows for resources like the crypto worker or thread workers to be resolved properly when used in a generic context.

[pavelsavara]

See also this #69441

[kg]

while we're changing this, it might make sense to have a convention for how to tell the runtime what its baseUrl is so it doesn't have to guess. i'm guessing uno could pipe that through

[lambdageek]

The guessing should be removed - and blazor updated to provide a base URL (and possibly also the URL of the worker script - actually depending on how much stuff they mangle we might need some locate function where we can ask for normal names that we know and blazor can tell us what they mangled them to). the guessing was just a hack because I didn't want to coordinate a pair of aspnetcore and runtime PRs

(I don't mean this current PR should remove the guessing and wait until blazor is updated - that should be done separately)

[pavelsavara]

guys, I don't have bandwidth to fully explore this space right now, but please make sure that you align it with NodeJS and that we have some consistent plan for the relative paths of configured resources. We have open discussion on the PR I mentioned above and also we have @radical 's host and maybe some new shape of the config.

All that said, I think we should just add dotnet-crypto-worker.js into mono-config.json as new resource type, rather than hard-code it here.

[pavelsavara]

Crypto worker is gone now.
For threads worker we do resolve_asset_path which uses now improved locateFile.

runtime/src/mono/wasm/runtime/pthreads/shared/emscripten-replacements.ts

Lines 39 to 42 in 3c21cc5

	const asset = resolve_asset_path("js-module-threads");
	const uri = asset.resolvedUrl;
	mono_assert(uri !== undefined, "could not resolve the uri for the js-module-threads asset");
	const worker = new Worker(uri);

So, I guess this PR is obsolete ? @jeromelaban

[jeromelaban]

@pavelsavara I guess it is! Thanks for the update.