fix: Overhaul of ColorConfig internals to solve perf issues (#3995)

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>