fix: Overhaul of ColorConfig internals to solve perf issues

First, some background: In the course of working toward OIO 2.5, we
added some heuristics that used OpenColorIO 2.2's new
isColorSpaceLinear, and also using its new "built-in config" to figure
out if an arbitrarily named color spaces in a user's config were
equivalent to some built-in ones that are commonly used.

All seemed well until... we recently discovered that it was moderately
expensive (~0.1s per color space!) on the OCIO side, which wasn't
particularly noticeable when I was testing, but can add up to several
seconds of needless startup time when inventorying large configs with
dozens and dozens of color spaces. And even worse, it was
exceptionally expensive for color spaces with LUT3Ds because of a bug
on the OCIO side that would invert the 3D LUT needlessly (taking >10s
per LUT3D inversion), leaving to MINUTES of overhead for some configs
with many such spaces.

So this PR attempts to work around all of this with several big
changes (which are amplified by the fact that I've really shuffled
around the code between methods and within the file, sorry):

1. Per suggestion from Doug Walker, there's a new heuristic to try to
detect if a color space from or to the reference space appears to
contain a 3D LUT, and if so, skip some of the more expensive
heuristics that appear to cause the LUT to be inverted. It's not
perfect, but we're making a bet that no LUT3D-involving color spaces
are going to be one of the few canonical spaces we're trying to
detect. This fixes the "10s of seconds of delays" problem for those
particular color spaces.

2. When using OCIO 2.3+, use its newly introduced utility
IdentifyBuiltinColorSpace to have it tell us which color space in the
user's config matches some of the canonical ones we care about in the
built-in config.

3. Whew, switch to a kind of lazy evaluation of the propererties of
each color space. Whereas before, we fully inventoried the config and
for each cs we found in it, do all the heuristics, now we only do the
inexpensive tests up front (silly rules of thumb where we guess based
on the *names* of the color spaces). We save the potentially more
expensive but thorough ones (like transforming some sentinel colors
around to see if the behavior of the cs matches a color space we care
about, and asking OCIO what it thinks about isColorSpaceLinear) only
if we are asked to do certain things with *that* color space. In other
words, a cs in the config that OIIO doesn't need to *use* in some way
will now not undergo the expense of the trickier investigation about
what it might be equivalent to.

These add up to making the overhead for ordinary use be significantly
sub-second, no longer a problem. Nature is healing.

Signed-off-by: Larry Gritz <lg@larrygritz.com>