Make RD settings/preferences portable/shareable/backup-able

[ThunderFrame]

Backing up and sharing common and consistent preferences between team members, between PCs, or across rebuilds would be nice feature.

Linking to #940

[rubberduck203]

This is already done, unless I misunderstand something. Your settings are store in the ~/AppData/Roaming/Rubberduck.config file.

[ThunderFrame]

Indeed the config file exists, but only the current config. #940 would add multiple configs)

[rubberduck203]

Oh! You want a Load button!

Yeah. Sure. That's a great idea. It just took a minute to click on my head. That's a good idea.

[rubberduck203]

This one may take an unfortunate amount of effort, and I blame myself for the bad design.
The different configuration services all inherit from a base service that knows where the setting files are stored, then each implementation provides it's specific file name.

https://github.com/rubberduck-vba/Rubberduck/blob/next/RetailCoder.VBE/Settings/ConfigurationLoader.cs

It worked really well for the purposes of the time, but will require some redesign to allow a user to load arbitrary settings files at runtime. I'm debating on whether or not it would be acceptable to add two overloads to XmlConfigurationServiceBase : IConfigurationService.

This is the current interface.

public interface IConfigurationService<T>
{
    T LoadConfiguration();
    void SaveConfiguration(T toSerialize);
    void SaveConfiguration(T toSerialize, bool languageChanged);
    event EventHandler SettingsChanged;
}

This is the interface I think I'm proposing.

public interface IConfigurationService<T>
{
    T LoadConfiguration();
    T LoadConfiguration(string filePath);
    void SaveConfiguration(T toSerialize);
    void SaveConfiguration(T toSerialize, string filePath);
    event EventHandler SettingsChanged;
}

Note that I removed the languagedChanged flag above. That's because this is occurring in the code.

    public void SaveConfiguration(T toSerialize, bool languageChanged)
    {
        SaveConfiguration(toSerialize);

        if (languageChanged)
        {
            OnSettingsChanged(EventArgs.Empty);
        }
    }

I can't imagine why we're only raising this event if the language changes, or worse, why the client code is responsible for figuring that out. Let's take a moment to clean this up while we're touching this code. Just raise the event. Doing this means that the event lies. It's not an OnSettingsChanged event, it's an OnLanguageChanged event. We'll need this event to communicate to the program that it needs to reload the settings to implement this feature request.

[retailcoder]

@ckuhn203 it was done that way because the only reason we needed to know when settings changed, was to re-create the menus in the new locale, and we didn't need/want to do that when anything other than the language setting was changed. The 2.0 menus no longer involve destruction/re-building of the app menus and windows, so that strategy is moot now.