Deduplicate identical inbox color schemes to heal user settings

[DHowett]

Up until now, we have treated inbox, fragment and user color schemes the
same: we load them all into one big map and when we save the settings
file we write them all out. It's been a big annoyance pretty much
forever.

In addition to cluttering the user's settings file, it prevents us from
making changes to the stock color schemes (like to change the cursor
color, or to adjust the colors in Tango Dark, or what have you) because
they're already copied in full in the user settings. It also means that
we need some special UI affordances for color schemes that you are
allowed to view but not to delete or rename.

We also have a funny hardcoded list of color scheme names and we use
that to determine whether they're "inbox" for UI purposes.

Because of all that, we are hesitant to add more color schemes to the
default set.

This pull request resolves all of those issues at once.

It:

• Adds an "origin" to color schemes indicating where they're from
  (Inbox, Fragment, User, ...)
• Replaces the Edit UI with a much simpler version that pretty much only
  has a "duplicate this color scheme to start editing it" button
• Deletes color schemes that we consider to be equivalent to inbox ones;
  this allows us to finally disentangle the user's preferences from the
  terminal's.
• Migrates all user settings that referred to schemes they may have
  modified (even implicitly!) to their modified versions.

The equivalence check intentionally leaves out the cursor and selection
colors, so that we have the freedom to change them in the future.

The Origin is part of a new interface, ISettingsModelObject, which we
can use in the future for things like Themes and Actions.

[DHowett]

is this bodgy i can't tell

[DHowett]

I'll include this in Leonard's new "Fix User Settings" code :)

[zadjii-msft]

Notes from team sync today (post hackathon)

• The SUI still needs updates
• Instead of making the builtin schemes read-only, just sneaky save them as the (Modified) version

[DHowett]

I am noodling on what the UI looks like when you try to edit one of these. We don't need to fun disclaimer text any more (woo), but we do need a call to action.

[zadjii-msft]

I'm gonna say . I'd maybe make it an InfoBar but that's basically the same UX

[DHowett]

Okay, this works pretty well.

[lhecker]

The fmt::format calls throughout the PR could use FMT_COMPILE IMO.

[DHowett]

The one risk I am aware of is that we will delete user color schemes that ONLY change the cursor or selection colors.

I can add checks to avoid this, but the risk seems fairly low overall.

[lhecker]

I think that's an acceptable risk.

[DHowett]

@lhecker any blockers left?

[DHowett]

Body updated

[lhecker]

I still don't quite understand how _addOrMergeUserColorScheme works without returning a bool fixup flag. It potentially renames the user's scheme, so why don't we need to trigger a save of the new (fixed) config?

[DHowett]

So! Because _addOrMerge is called during settings loading and we don't have a place to store "I did fixups" outside of FixupUserSettings, I opted to instead track the observable effects of merging.

This line in CascadiaSettingsSerialization ensures that we write out the settings if we renamed a user color scheme. Because renaming adds a remapping entry, the condition will always reflect whether there have been any renames.

The one case this does not cover is when a user had an identical color scheme which we deleted, but no other settings changes. Honestly, I don't mind that terribly. If they go save their settings again it will disappear, and it is not harming anyone much by being there.

I can plumb through a "made changes" flag if we want to force a flush to disk when we delete schemes.

[Machine391]

Added
Continue script