…o pass context to `resolveFileUrl` hook (#10297)

This PR adds a new feature to `import.meta.ROLLDOWN_FILE_URL_<referenceId>`.

Currently, these file URL references does not have a way to differentiate each references when `resolveFileUrl` hook is called. But that is sometimes needed. For example, in Vite, there are three cases:

- The wasm plugin emits the reference to the wasm binary. In SSR, this reference to the wasm binary should be rendered in a way that accesses as a relative path (as it's a file read). But in other plugins, the wasm binary should be rendered as the URL that can be accessed from the browser (this may sound strange, but it's the current behavior). So the `import.meta.ROLLDOWN_FILE_URL_<referenceId>` needs to be differentiated with type it is.
- Vite has `?inline` query which forces the asset to be output as `data` URL. The same asset can be imported with the query in some places while it can also be imported without the query in other places. This means the same asset needs to be referenced differently depending on the reference.
- Vite never inlines assets specified as the entrypoint. This information is tied to a single reference.

[rendered docs](https://github.com/rolldown/rolldown/blob/07-15-feat_import.meta.rolldown_file_url__referenceid___urlid_support_to_pass_context_to_resolvefileurl_hook/docs/apis/plugin-api/file-urls.md#passing-a-urlid)

In this PR, I made the `urlId` generated on the plugin side, but maybe that should be generated on the Rolldown side so that a conflict never happens. This can be done by adding `this.generateFileUrlId`.

The API can also be expanded to store the metadata in the Rolldown side. Currently, The metadata lives on the plugin side, so the referenceId emit and the `resolveFileUrl` hook needs to be coupled. This works for Vite's case, but won't work in general. For now, I think it's ok to go without it.

refs vitejs/vite#22962