Add support for project-level and part-level settings

[franknoirot]

Currently we have only one block of settings that are shared between all projects and files. As @JBEmbedded pointed out, this can lead to confusing behavior if a user thinks they are setting something like the Base Units for their project to Centimeters, then come to find that their units have changed in another project they meant to keep in Inches.

### Tasks
- [x] Create an architecture plan, looking at VS Code and Obsidian's config systems as inspiration
- [ ] Create a way to define user-level settings, project-level settings, and part-level settings
- [ ] Make it possible to read and write these settings from files (#1361 extended)

[franknoirot]

Relevant research items:

1. https://code.visualstudio.com/docs/getstarted/settings
2. https://help.obsidian.md/Files+and+folders/How+Obsidian+stores+data#Vault+settings

[franknoirot]

More relevant research: a substantial number of obsidian power users hate that it defaults to per-vault settings, and that it lacks a way to set global defaults for new vaults (our equivalent is projects).

[franknoirot]

I've made a Figma mockup flow here. Here's the most important screen from it:

Requirements

• [ ] Make settings into a modal (but keep the routing functionality)
• [ ] When entered from /home, the modal will only show one tab for "User"
• [ ] When entered from /file/[id], the modal will show three tabs: User, This Project, and This Part, with This Project selected
• [ ] Editing the User tab saves only changed settings to the App Data directory as settings.json, and is used as the setting value if no overrides are set for This Project
• [ ] Editing the This Project tab saves only changed settings to the project's directory, and is used as the setting value if no overrides are set for This Part
• [ ] Editing the This Part tab saves only changed settings to the same directory as the currently-opened part within a [id].settings.json file, and is used at the setting value.
• [ ] Editing a setting via the command bar from Home changes the User-level setting
• [ ] Editing a setting via the command bar from a file changes the Part-level setting if possible, Project if not, and User if Project is not allowed.
• [ ] Theme will be the first setting that is only able to be set at the User level

[franknoirot]

Starting implementation of this now, here's my plan.

• I'm planning on storing the settings in a tree-like object where the nested objects are categories and subcategories, and leaf node objects are settings.
  • This tree will be only one level deep for now, no subcategories.
• The leaf node objects must have at least a default value provided by Modeling App, but can have overrides at the user, project, or part level.
  • For now I think I'll allow any setting to be overridden for each level, but in future I think we may find that some settings don't make sense to be set at all scope levels (I mentioned theme in a previous comment), and we'll want to make that more restrict-able.

An example

Here is an example settings object (the context of settingsMachine) after reading in the default, user, project, and part-level settings files:

const settings = {
  units: {
    length: {
      default: "millimeters",
      user: "inches",
      part: "millimeters",
    },
    angle: {
      default: "degree",
      project: "radians",
    },
  },
  editor: {
    mouseControls: {
      default: "Zoo",
    },
  },
}

In the example above, the user has the following settings files on their desktop app. Note that these will likely be .json files, but I'm showing them as JS settings constants for comparability to the object above:

in $APP_DATA/settings.json:

const settings = {
  units: {
    length: "inches",
  },
}

in <some-zoo-project-dir>/settings.json:

const settings = {
  units: {
    angle: "radians",
  },
}

and in <some-zoo-project-dir>/<part-name>.settings.json:

const settings = {
  units: {
    length: "millimeters",
  },
}

So the settings are applied as follows:

1. No overrides are saved for mouseControls, so we use the default "Zoo" value
2. A project-level override is provided for units.angle, so we use "radians" instead of the default "degrees"
3. Both a user- and part-level override are provided for units.length, so we use the part-level override that takes precedence.

[franknoirot]

If we're going to write to and read from a settings file within the current project's directory and using the current part's name, we have to find a way to resolve the fact that currently the settingsMachine doesn't know about the existence of the fileMachine or indeed the currently-open project or part at all.

I think that we need to do the work of #1248 and then we can implement an actor system to avoid this "which machine is truly global" and let them coordinate across each other responsibly.

[franknoirot]

While this actor system is very compelling from my first forays into implementing it, I think it's impractical to make the changes I outlined above right now. While I believe it would ultimately be less code, it would nearly touch every file in the repo.

Instead, I will do solve only the problem at hand by hoisting the FileMachine up to live alongside the Settings and Auth machines, giving Settings access to the currently-opened project and file to allow it to know where to write to.

I will post my findings from exploring the XState V5 actor model into a separate issue, because it will be a substantial refactor if we do it.

[franknoirot]

After discussing a bit more with @Irev-Dev I'm making two more requirements changes:

1. We're not going to support Part-level settings in this manner. We will likely allow them in a "cargo-script"-like manner down the line.
2. We'll write these to .toml files, since we were planning on having a project.toml with project info soon anyway. The settings can simply live under a [settings] section.

[franknoirot]

A more fine-grained tasklist:

- [x] rework settings config to easily add to settingsMachine
- [x] persist only changed settings to the appropriate files
- [ ] read persisted changed settings from the appropriate files
- [ ] change settings to modal appearance
- [ ] make all settings show up in command bar
- [ ] make level argument skipped and fixed when not in a project
- [ ] make settings modal UI derived
- [ ] Make commands have optional labels, generate these to look better for settings