Color Table Window Redesign: Fix loading of filtering selection so it does not require band-aids all over the code

[JustinPrivitera]

To make saving the color table tag filtering selection saveable and loadable in #17721, I had to jump through a number of hoops.

1. The color table observer includes a fail-safe in the Update() function that makes sure that the list of color tables and the list of toggles are the same size (it should be a 1 to 1 relationship). This fail-safe should never have to be activated, but there is an issue with loading settings from config/session files, which cause the list of toggles for color tables to be empty when execution reaches this function. The underlying issue (somehow the toggle list is empty when reading from saved settings) needs to be investigated and fixed.

// This should never happen. Resetting the names will reset the active
// array as well, and make very color table active. However, this does
// happen; when loading settings from config/session files, `names` is
// populated but `active` is left empty. Ideally, loading settings
// would correctly preserve which color tables are active, but this
// final guard here works just fine, as which color tables are active
// is calculated after this.
if (names.size() != active.size())
    colorAtts->SetNames(names);

2. The UpdateNames() function for the Color Table Window has a code block at the end that must be run only once.

static bool run_before = false;
if (!run_before)
{
    // This only needs to happen the very first time for loading options.
    // If visit isn't opened with saved config and guiconfig files, then
    // this is redundant, but doesn't hurt. If it happens more than once
    // then VisIt will crash.
    run_before = true;
    colorAtts->SetChangesMade(true);
    ctObserver.SetUpdate(true);
    Apply(true);
}

This occurs so that the filtered down list of color tables appears in all the buttons. It also only ever needs to happen once, because of the order of execution of functions when loading saved config/session files. Before this band-aid, the buttons didn't get updated with the filtering selection until users clicked something in the color table manager, which is a bug. However, if it happens on every call, VisIt will not only freeze, but you will also be booted off your compute node. Calling Apply() shouldn't happen in UpdateNames(), since it'll circle around (I think?) and call UpdateNames() again. Hence the static bool to force it to happen just the first time. I need to figure out why the color table observer isn't doing it's job when VisIt loads config/session files, fix it, and ideally remove this code.

I have grouped these 2 problems into one issue because they both relate to the loading of saved session/config files. So the things to fix are 1) correctly saving and loading which color tables are "active" (toggled on (appearing in the filtered list)), and 2) switching up the order of execution within the GUI so that the color table observer pays attention properly when info is first loaded from config/session files.

[JustinPrivitera]

Fix the issues here as much as possible (race condition on start up?) and then think about how the gui could be modified in the future to be more sensible.

[JustinPrivitera]

Other problems include things like this:

UpdateNames();
colorAtts->SetChangesMade(true);
ctObserver.SetUpdate(true);
Apply(true);

[JustinPrivitera]

As well as the tagChangesMade and changesMade in the CCPL and CTAtts respectively.