Houdini 20.5: expose MoonRay Solaris material builder

[rolledhand]

This supports OpenMoonRay/openmoonray#228.

Summary:

• Installs Houdini toolbar resources with the DCC plugin payload.
• Adds a MoonRay Material Builder tab-menu tool for Solaris Material Library.
• Creates an editable MoonRay-native subnet with DwaBaseMaterial wired to surface and NormalDisplacement wired to displacement.
• Keeps the MaterialX vopnetMask compatibility bridge separate from the native builder path.

Validation:

• Sourced scripts/macOS/setupHoudini.sh against Houdini 20.5.684.
• Created the builder under /stage/materiallibrary1 from the GUI tab menu.
• Exported USD with outputs:moonray:surface and outputs:moonray:displacement.
• Rendered with husk -R HdMoonrayRendererPlugin; RDL contains DwaBaseMaterial and NormalDisplacement; EXR is non-black.

[rolledhand]

Domelight support added, the Moonray tab now also exposes the parameters which work. DCO signed off.

Before Moonray tab exposure:

After Moonray tab exposure:

Parameters get read, translated, and work.

[rolledhand]

Created a dedicated Moonray subnetwork for material authoring, kept the usd mtlx still open and added. It can be removed in the future.

[rolledhand]

Keeping this PR mostly UI related from now on whilst keeping the main OpenMoonRay PR IPR and functionality imagery focused for now.

Render geo settings - new UI tab exposure from older commits:

[rolledhand]

Latest commit exposure of native Moonray spotlight, the spolight controls were initially exposed at the end of the properties tab. Creating a dedicated tab for spolight with a checkbox to switch over to the native Moonray controls looked like way more artist friendly solution to me.

[rolledhand]

This is an initial dedicated artist-friendly native "MoonRay Render Settings" node kickoff. It's still in an early-stage work-in-progress state, since proper functionality takes precedence.

At first I tried to create, and am still in the process of creating, a native Solaris "top bar", so to say, aligned with how other engines structure their nodes. This also includes the resolution presets. The design still isn't there, but defining the resolution works now.

My next "artist-friendly" plan is to create an "AOV tab" which will not expose all variables directly, but rather work as a simple checkbox UI with the correct predefined values for ease of use. This still requires establishing working backend functionality first.

The "Sampling" tab has been introduced. Currently, selecting uniform sampling disables only the adaptive sampling parameters, but I also want to introduce the inverse behavior: disabling uniform sample parameters when adaptive sampling is selected, to avoid confusion and make the behavior feel natural.

Again, this is early stage. I'm also planning to reduce the number of tabs and place parameters into better-fitting tabs, for example sample clamping could live with the other sampling controls here.

The rest is purely a preview of other tabs and will be developed further. At the moment I am considering leaving "driver", "logging", and "debug" tabs unexposed for the "artist-friendly node". Still too early in development to make final design decisions.