feat: support rollup plugin this.load in plugin container context

[luxaritas]

Description

This adds support for calling this.load (added in Rollup 2.60) in a rollup plugin when using a plugin context via Vite's plugin container (namely, when using the dev server).

Resolves #6810

Additional context

This fixes the issue I have in my specific use case (rollup-plugin-typescript2 needing to call this.load, though not using any of its output - I tested this PR locally with that test case), and is strictly more functional than the previous lack of support. However, there are some limitations which I don't know if it's appropriate to address or otherwise present issues:

• The return of this.load from Vite will be a ModuleInfoProxy, which doesn't include most of the properties from ModuleInfo. I imagine some plugins are likely to be calling this.load expecting some of these parameters to work. That said, this is already an existing limitation of getModuleInfo, so I assume that is out of scope.
• Further, this.load is supposed to trigger transform and moduleParsed - this does not (in accordance with vite's on-demand nature)
• The resolveDependencies parameter is left unused, as since the modules are not actually transformed/parsed, from my understanding dependency information is unavailable/irrelevant
• ModuleOptions properties other than meta are unused (though as far as I know, that's the responsibility of updateModuleInfo, and so out of scope, and presumably unnecessary in the on-demand situation)

I don't have much experience working at this level, so feedback is definitely appreciated, and I'm happy to make any adjustments

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[sapphi-red]

Thank you for the PR!

[sapphi-red]

TIL about this 😮

const p = new Proxy({}, { get() { throw new Error('foo') } })

async function foo() { return p }

;(async () => {
  await foo() // error
})()

[luxaritas]

Yeah that threw me for a loop initially - I believe this is due to async/await being syntactic sugar for a promise, and promises being able to return promises, so the runtime needs to "probe" for a .then() on the return to see whether it needs to chain the promise.

[bluwy]

Sorry for attending this 2 months late 😬 Let's get this in 4.2