Use case for `move()` from OPFS ↔ user-visible file system

[tomayac]

In Moving Non-OPFS Files, @a-sully asks for use cases for compelling moving files in-between file systems. One such use case could be moving large files (example), where the user doesn't have enough free disk space to allow for a copy.

[jed]

Another example is to defer permission requests until needed. For example, an IDE that:

1. pre-populates the OPFS with a folder containing project scaffolding (src, lib, package.json, et al),
2. lets me view and edit those files/directories, and then
3. lets me move them to my local drive once i'm ready to grant write permissions.

[Jaifroid]

I also need to be able to move, rather than copy, files from visible to OPFS and vice versa. Ideally this would work on Android, though I think lack of the showOpenFilePicker and showDirectoryPicker methods on Android could be a blocker.

I have a PWA -- offline Wikipedia (Kiwix) -- that deals with often very large archives (2GB would be standard, but archives can be up to 97GB). While I don't expect to be able to move a 97GB file into OPFS (though it would be a dream come true if I could in a relatively performant manner), being able to move 2GB archives in and out without the overhead of copying and doubling disk-space requirements would enable our users to download these large archives outside of the app, transfer them in and then access them seamlessly (without permission prompts) and with greater performance than when accessing files from visible storage.

The specific use-case for Android is because access to the visible file system is dog slow in Android web apps and clunky because the user needs to re-pick files at the start of every sesxion. But without showOpenFilePicker I suppose we'd be stuck with copying in and out (and probably have to "donwload" files from OPFS).