Increased Flexibility in Theme Configuration System

[YourRobotOverlord]

I would love to see increased flexibility in the theme configuration system in TG.
To this end, I think SchemeManager should not throw an exception when a named scheme is not found in the config file.

Some examples of where it would be useful:

• If a developer sets the SchemeName of a view (as I always do for all TextInput views), the theme must also contain a definition for it.
  Right now, any existing themes, or the TG hardcoded defaults, are incompatible and will cause an exception.
• The end-user deletes the config file altogether to get away from a bad configuration.
• An end-user makes a typo while editing the config file.

My proposal is to implement a more robust fallback system. For example, View.GetScheme does have a partial fallback path, but only if SchemeName has not been set:
SuperView scheme -> Base scheme

What I propose uses the following fallback path in all cases:
Requested scheme -> Superview scheme -> Base scheme -> Hard-coded Base scheme

This would have the added benefit of allowing scheme definitions to be simpler, for example you could just set:

            "Base": {
              "Normal": {
                "Foreground": "White",
                "Background": "Black",
                "Style": "None"
              }
            }

This would be enough to define the theme for the entire app.

I have played around with this a bit and managed to get something working:

In SchemeManager, I added TryGetScheme:

    public static bool TryGetScheme (string schemeName, [NotNullWhen (true)] out Scheme? scheme)
    {
        lock (_schemesLock)
        {
            var schemes = GetSchemesForCurrentTheme ();

            if (schemes.TryGetValue (schemeName, out var s) && s is not null)
            {
                scheme = s;
                return true;
            }

            scheme = null;
            return false;
        }
    }

In View.Drawing.Scheme, I replaced GetScheme:

    public Scheme? GetScheme ()
    {
        ResultEventArgs<Scheme?> args = new ();

        return CWPWorkflowHelper.ExecuteWithResult (
                                                    resultEventArgs =>
                                                    {
                                                        bool cancelled = OnGettingScheme (out Scheme? newScheme);
                                                        resultEventArgs.Result = newScheme;

                                                        return cancelled;
                                                    },
                                                    GettingScheme,
                                                    args,
                                                    DefaultAction)!;

        // Only this part is modified
        Scheme? DefaultAction ()
        {
            if (HasScheme)
                return _scheme;

            if (!string.IsNullOrEmpty (SchemeName) &&
             SchemeManager.TryGetScheme (SchemeName, out Scheme? scheme))
                return scheme!;

            return ResolveFallbackScheme ();
        }
    }

and added a fallback resolver:

    private Scheme ResolveFallbackScheme ()
    {
        return SuperView?.GetScheme ()
            ?? SchemeManager.GetScheme ("Base")
            ?? SchemeManager.GetHardCodedSchemes ()! ["Base"]!;
    }

Yes, its unrefined, incomplete, probably faulty, and probably breaks other things, but it proves the concept.

Custom theme with TextInput scheme defined:

Switching to a theme without TextInput defined and everything still works:

I think that even if most end users never open a config file to edit a application theme, enough do to consider it an "end-user feature".
I also think a goal for any feature intended for end-users should be that it never throws exceptions, because the end-user screwing it up is not exceptional.