Support file I/O in browser version of authoring tool

[mkremins]

The Ensemble authoring tool is capable of running as both a desktop app (via Electron) and a clientside-only web app (via any major web browser). The browser version of the tool, however, can neither load existing domain/schema JSON files nor save out new ones.

There's a few reasons why supporting file I/O in the browser version of the tool would be useful IMO:

• The browser version of the authoring tool substantially reduces the barrier to entry for prospective new Ensemble users. The more full-featured it is, the better.
• If the browser version of the tool supports file I/O, there won't be as much pressure on us to prioritize fixes to the desktop app build toolchain every time it breaks, because Ensemble domain authors will be able to use the browser version of the authoring tool as a stopgap alternative. The desktop app build toolchain has historically been the most fragile and complicated part of the Ensemble development process, and will probably continue to be fragile in the future.
• Adding support for file I/O in the browser version of the tool might actually simplify some of the file I/O code for the desktop version of the tool, since I'm pretty sure both browser and Electron apps can use <input type="file"> to accept file uploads.

If we decide we want to do this, I've also included a bit of information here about the difficulties we might encounter on both the input and output sides.

Input

The major obstacle here is that the desktop version of the tool is currently written to accept a whole directory of JSON files as input, and <input type="file"> doesn't technically offer any standard cross-browser way to upload an entire directory in one go. The webkitdirectory attribute enables directory uploads, and actually appears to be supported across all current major desktop browsers as far as I can tell, but I'm not sure how comfortable we are with the prospect of relying on a technically still-nonstandard API.

Alternatively, the multiple attribute allows you to select a bunch of individual files within a single folder and batch-upload those, so we could maybe use this instead if we decide we don't like the webkitdirectory method.

My understanding is that Electron augments the <input type="file"> API to record full filesystem paths when a file is "uploaded" to an Electron desktop app. Therefore, if we unify the file input methods across the desktop and browser versions of the app, the desktop app should still receive access to the full paths, which it can then use to automatically save changes to the original input files like it always has.

Output

The major obstacle here is that browser apps can't write to desktop files without user interaction. You can give the user a button that lets them download a modified version of their domain/schema files to wherever they'd like on the local filesystem, but you can't directly modify the original input files in place like the desktop version of the tool currently does. Therefore, users of the browser version of the tool would have to save their work out manually once they were done modifying their domain.

We could probably make judicious use of localstorage APIs to ensure that work isn't lost completely if the user happens to close the browser version of the authoring tool without re-downloading their domain files. Also, the desktop version of the tool would still be able to modify domain files in place like it always has, using the existing file I/O code.