feat: add enable partial load setting to GUI

[psychedelicious]

This adds a checkbox to the settings to override the enable_partial_loading setting.

Because this uses an env var to control the setting and it overrides any settings in invokeai.yaml, it could cause some confusion. Marking this as draft pending more time to think through the issue.

[iwr-redmond]

Could you add an internally documented (hidden) CLI argument to Invoke that prompts the Python package to save particular predefined environment variables passed from the launcher to invoke.yaml? e.g. _save_launcher_managed_arguments=True? It would be nice to be able graphically set INVOKEAI_MODELS_DIR as well (greedily, says he!), and this poses the same challenge.

[psychedelicious]

That's an interesting idea! But there's a issue - it implicitly assumes that the launcher version is tied to the app version, which is not true. Settings set via the launcher could be invalid for the app version and even cause crashes.

The change in this PR has the same problem, as would any more involved settings management from the launcher.

I think the best UX would be individual UI widgets for each setting in the app (not launcher).

Another option is to add a YAML editor to the launcher. But then that's a lot of effort when we could instead just direct users to edit the YAML file directly w/ a text editor.

I think we will focus on reducing friction for users to edit their invokeai.yaml rather than build the settings UIs:

• Add a button to the launcher to directly open the YAML file in the user's text editor.
• Publish a JSON Schema for the YAML file, which would allow text editors to give you autocomplete for it (see VSCode's JSON settings for an example of this). Doesn't help non-technical users but I'd love to have it.
• Update the example YAML file with comments for each setting. This file is regenerated on every app launch so it would always be updated.

[iwr-redmond]

Settings set via the launcher could be invalid for the app version and even cause crashes.

If you have some sort of communication flag the Python package is waiting for, future versions could respond with 'update your launcher, please!' and invalidate any environment or YAML variables it no longer recognizes. I reckon that would be a net benefit, because less technical users with older settings would be protected (somewhat) from the impact of failing to remove deprecated YAML flags. The only catch would be that the communication flag would have to be long-term.

EDIT: Apologies, long day! Old variables with INVOKEAI_xxx fed to the Python launcher -> unrecognized -> if the communication flag is present, wipe out these variables from the YAML file & warn the user to update the launcher.