fix: keep CompileOptions includer alive across copy and move

[Sakura-501]

Summary

This fixes a use after free in shaderc::CompileOptions when a custom includer is configured through SetIncluder() and the options object is later copied or moved before preprocessing or compilation reaches #include.

Vulnerability details

SetIncluder() stores the includer callback state in two places:

• the C++ wrapper keeps ownership in CompileOptions::includer_;
• the underlying C options object stores raw callback function pointers plus include_user_data.

Before this change, copying CompileOptions only cloned options_, and moving it only transferred options_. The registered include_user_data therefore kept pointing at an includer owned by a different CompileOptions instance. Once that source object was destroyed, any later #include preprocessing path could call through a dangling pointer and trigger a heap use after free.

Both copy and move paths were affected. A remote shader compilation service that registers a custom includer and passes CompileOptions by value could be crashed with a single shader containing #include.

Fix

• store the C++ includer in a std::shared_ptr so its lifetime can safely span copied CompileOptions objects;
• re-register the include callbacks after copy and move so the underlying C options object always uses the current include_user_data;
• clear the callbacks when SetIncluder(nullptr) is used;
• add regression tests that prove the includer remains alive after the source CompileOptions instance is destroyed and that preprocessing with #include still succeeds.

Verification

• cmake --build build-test --target check-copyright -j4
• ./build-test/libshaderc/shaderc_shaderc_cpp_test