Allow conigure local custom storage drivers

Environment

nitropack@0.4.24
$ node --version
v16.17.0

Reproduction

Follow the example of unstorage https://github.com/unjs/unstorage#making-custom-drivers
I used the original memory driver as "custom driver"

import { defineDriver } from './utils'
import type { StorageValue } from '../types'

export default defineDriver(() => {
  const data = new Map<string, StorageValue>()

  return {
    hasItem (key) {
      return data.has(key)
    },
    getItem (key) {
      return data.get(key) || null
    },
    setItem(key, value) {
      data.set(key, value)
    },
    removeItem (key) {
      data.delete(key)
    },
    getKeys() {
      return Array.from(data.keys())
    },
    clear() {
      data.clear()
    },
    dispose() {
      data.clear()
    }
  }
})

Describe the bug

The current interface for storage options is:

interface StorageMounts {
    [path: string]: {
        driver: BuiltinDriverName | CustomDriverName;
        [option: string]: any;
    };
}

but unstorage allows the use of custom drivers and we are not using them.

Additional context

I found https://github.com/unjs/nitro/blob/main/src/rollup/plugins/storage.ts
on line 47

${driverImports.map(i => genImport(i, genSafeVariableName(i))).join('\n')}
I am not quite sure if that means we should do the following

storage:{
  db: {
    driver: "../../../../CosmoDriver.js",
    options: {
     // my driver options 
    },
  },
}

This kind of complex and error prone
We should allow the user to pass in the driver directly and just
driver:new Driver({})

Logs

No response

Start with src/rollup/plugins/storage.ts, especially the driverImports generation around line 47, and trace how StorageMounts and custom drivers are currently resolved. Compare that flow with the unstorage custom-driver example in the issue; the work is done when users can configure a custom driver directly without relying on complex generated path imports.