Desktop user experience overhaul

[SleepyLeslie]

This PR refactored a major portion of Grist Desktop:

• Dismissed use of symlinks (properly fixes #4). See below for details. Closes #25.
• Implemented WindowManager.
• Implemented importing from the "file" menu (closes #3, but needs more testing).
• Revamped the intricate pendingPathToOpen mechanism to make it more straightforward.
• Removed shouldQuit and handle single instance locks outside of GristApp.
• Moved all CLI argument handling code together, including the macOS -psn_ argument hack and file opening logic.
• Replaced preload.js with preload.ts, and set up electron IPC properly.
• Cleaned up the codebase and removed some now unused functions.

Filesystem changes

Grist Desktop used to rely on symlinks to comply with Grist Core's requirement that all documents be stored centrally in GRIST_DATA_DIR. This causes issues on Windows, and impacts the user experience since users cannot choose where to store their Grist documents.

Moreover, this contributed to a bad user experience as documents use docID as name, and GRIST_DATA_DIR defaults to the "Documents" folder. This means users will end up having a lot of <random string>.grist files in their "Documents" folder.

It has also led to complaints from macOS users, since they basically cannot use Grist Desktop without granting permissions to the "Documents" folder.

This PR enables Grist Desktop to open Grist documents anywhere on the local filesystem, without making symlinks. All modifications will directly write to the document.

Window manager

Grist Desktop now knows all documents it has open, and would bring the open document to you if you open it twice. It can keep track of window content changes (i.e. when a user navigates away from / into a document).

It must work together with this PR for grist-core https://github.com/gristlabs/grist-core/pull/1099

[SleepyLeslie]

Tested to work on Linux, Windows 10 and Intel Macs; can open documents and symlinks to documents anywhere on the filesystem.

• macOS open-file events are handled correctly.
• Can use CLI argument to open file (Windows and Linux) correctly.
• Single instance lock is handled correctly.

Changes unrelated to the filesystem don't seem to break anything (good!)

Some comments:

• Can no longer create new document. This is because new documents don't have externalId by default. More changes to grist-core is required. This must be fixed. We can probably also support the "file -> new" menu properly.
• To prevent opening the same document twice, grist-desktop tracks open documents with a map from document IDs to Electron windows. If a user attempts to open an already open document, the corresponding window is raised. However, this mapping doesn't change when the user navigates to the home page or to another document, leading to weird behavior.
• After a document is deleted, it is still shown in the "All Documents" list. Attempting to open it will result in an unrecoverable error. It can be dismissed by clicking outside and going back to the home page, but this is bad UX. We should report an informative error message (rather than the dummy "error accessing document"), take the user back, then delete the entry from the database automatically.

[SleepyLeslie]

Now it is possible to create new documents using the in-app "Create Empty Document" button. However, this button will only work for the electron user. Should any user choose to use Grist Desktop as a self-hosted server, external visitors will now be unable to create new documents - they will get an error when clicking on the button.

[SleepyLeslie]

Implemented WindowManager to track open documents properly.

[paulfitz]

Trying this out a little bit.

• For Add New -> Create Empty Document, where does the document go? I don't see it in the target I set in the dialogue. I can see externalId set in the database to e.g. /home/paulfitz/Downloads/test123.grist but I don't see an actual file there.
• Likewise Add New -> Import. In both cases, dialogue looks encouraging, and doc opens well, I just don't know where it is on disk.

[SleepyLeslie]

The home page "Import Document" button and "File - Open" menu both work now. Import still "uploads" the document - a little clumsy but gets the job done easily. To avoid copying the imported document, we must rethink how to map the file into the sandbox for all possible sandbox flavors. This is out of scope for now.

"File - Open" now offers an "importable documents" filter. The user would first choose the file to import, then specify where to store the newly created Grist document. Again, not the optimal user experience, but a good balance taking implementation complexity into consideration.

[SleepyLeslie]

I don't see an actual file there

This branch is currently suffering from a resolve-tspaths issue that wrongly resolves stubbed files. Normal building procedure cannot produce a usable build containing the FS changes. A build produced this way still uses old components to handle getPath(), so will not create the file at the externalId location.

For now, it must be compiled without invoking resolve-tspaths. yarn electron:preview can be used to preview the build without actually building it.

[SleepyLeslie]

When a document is deleted, it is first trashed. When the user deletes the document permanently from trash, fse.remove() is called on the path obtained by getPath(). Something bad could happen when for example:

1. User creates ~/Documents/foo.grist from Grist Desktop.
2. mv ~/Documents/foo.grist ~/Documents/bar.grist
3. mv ~/Downloads/baz.grist ~/Documents/foo.grist
4. User deletes the document foo permanently from Grist Desktop. Grist Desktop doesn't know that the underlying file has changed, and will delete ~/Documents/foo.grist permanently, even if it is not the original foo document.

In general, desktop apps should not deal with document deletion. Some macOS native apps (e.g. MS Excel) seem to deal with this situation using macOS' "recents" API with filesystem integration (there must be some inotify involved), but we'd better not bother doing anything special for macOS.

I am not touching this behavior for now. Users should be careful not to delete documents by accident.