Use a single settings file and refactor settings

[RunDevelopment]

This PR completely changes how we do settings. Instead of the weird local storage thing we did, all settings are now stored in a single settings.json. The main process is responsible for reading and writing settings.json. The renderer can read and write settings via ICP channels.

The main advantages of this architecture are:

1. It's clear who owns settings (the main process). We previously had this weird hand-off where the render process suddenly gained ownership of the settings.
2. A single settings.json is easier for users to edit and for us to change (settings migration).
3. Settings are now strongly typed, and there is only a single parser for settings. This makes settings easier to use since we don't have to remember the keys anymore.
   Turned out, backend package settings were actually parsed incorrectly in CLI mode. Not anymore.

Since the new settings use a single settings.json, there is a migration from the old format (see tests for an example). This migration is the old reason why node-locastorage is still a dependency. We can remove it in the future, but it's still necessary right now for the backwards compatibility.

I also added something called "storage." Storage is accessed using the useStored(key: string, default: T): T hook. This is basically a drop-in replacement for the old useLocalStorage hook. The main difference is that useStored will store its values in settings.json.
The difference between storage and settings is that settings are used across UI components while stored values are basically useState of a single component that is remembered across restarts (e.g. when the node selector is open or closed). Storage is less structured.

Tbh, I'm not too sure about storage. This could just be localStorage, but I'm not sure how that would work with migrating settings. Maybe we'll change that in the future. Idk.

One thing that I haven't tested enough yet is performance. Since settings are completely reactive now, there can be more re-renders than before. This can cause perf problems. The node selector optimization PRs I recently did were because of this. Perf seems to be the same as without this change, but this still needs more testing.

---

It goes without saying, but this is a deep change. We should probably release this at the same time as #2597.

[joeyballentine]

Looks like this works, and I like the new elegance of the settings context. Is this ready for review now?

[RunDevelopment]

Yes. It seems to work fine in my testing.