Optimize: Avoid std::string allocations in string comparison

[brechtvl]

This could take up ~25% of config loading time with e.g. the ACES Studio Config or the Blender configuration. This is around 2-3ms on Apple M3 Max.

[brechtvl]

For context, Blender CLI warm start is about 10% spent inside OCIO, and AcademySoftwareFoundation/OpenImageIO#5490 reminded me to look into that.

This PR is an easy win, and most of the other overhead is in yaml-cpp. As a quick test, I used AI to generate code to use rapidyaml. And indeed that's where the next big win would be, though I don't think it's important enough for Blender cases for me to pursue that.

Commit	default (ms)	studio (ms)	blender (ms)
main	3.89	11.13	10.42
Avoid std::string allocations in string comparison	3.30	7.96	7.81
Combined other minor optimizations	3.25	7.59	7.53
Replace yaml-cpp with rapidyaml	0.58	1.20	1.07

[KevinJW]

Yes, I've felt that our string/char * handling probably could benefit from some targeted optimisation. I've found a number of cases where we construct std::sting rather than use std::string_view, or where we strip off the "string" wrapper pass a bare pointer and then do something involving finding the length of the buffer which the "string container" probably already had.

A lot of it comes from code policy not wanting std::string in the API and most of it being written before string_view was available.

[brechtvl]

Yes, I can see the code would benefit from string view more generally. It was especially bad here because it's allocating twice for every color space in linear searches over them.