fix: always resolve runner's entry point

[sheremet-va]

Description

Related: #16358 (reply in thread)

Passing down a non-resolved ID to the module runner works for loading files, but it creates invalid module cache entries that don't work with HMR.

cons runner = new ModuleRunner()

// all of the IDs are different from the module cache id
runner.import('./some-module')
runner.import('./some-module.ts')
runner.import('/some-module')

To resolve this, we always need to resolve entry points the same way Vite resolves URLs in the import analysis plugin. I see two possible solutions:

1. Share the code between the import analysis plugin and fetchModule (implemented in this PR)
2. Run the entry point module in some kind of "inlined" or "virtual" wrapper so the code is processed by Vite - this requires the user to define a plugin for this sort of thing, or we can have a built-in plugin that just injects an ID into an import, but this will probably break HMR in some way:

load(id) {
  return `export * from '${id}'`
}

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[bluwy]

I don't particularly understand the usecase for fetchModule case yet, but I think this make sense. It would be nice if we can properly extract out normalizeUrl() from import analysis entirely in the future so it's something others could use too.

For the test, I think we can skip the hmr circular one for now, but I think it's correctly flagging a bug that we should look into later.

[sheremet-va]

It would be nice if we can properly extract out normalizeUrl() from import analysis entirely in the future so it's something others could use too.

Agree. Vitest has actually a use case for this in the mocker.