Improve Houdini integration and documentation

[nshelton]

We need to define what Moonray - Houdini integration looks like, and what the current gaps are.

At first we shipped some out of date .hda files. We now have an internal script to update the .hdas included in
OpenMoonRay/moonray_dcc_plugins#5
as well as some updates.

But I notice @gripeyes has also started doing more solaris work here
OpenMoonRay/moonray_dcc_plugins#3

Which is probably too large of a change to merge for us and may interfere with what we have provided. But I wanted to start a space to discuss what the community would like to see as far as Houdini integration and what direction we should be heading.

[gripeyes]

Hey @nshelton , I believe in simplicity, so I'll start with the simple definition. The gap I'd like to close is for Moonray to feel like a well designed artist-friendly render engine implementation inside Solaris out of the box. Now, that I made it sound easy, the question is how to make it work that way from the "under the hood" perspective.

I just had a chance to give your latest PR a try. Quite a lot of things got exposed which is great, I gave it a try along with the new hdmoonray from Rob. There are still a couple of things I think can be implemented from what I was building before:

1. exposed native moonray material subnetwork under material library
2. exposed native moonray light filters under the light filter subnetwork
3. exposed mesh tesselation/subdivs under render geometry settings node
4. created of a native moonray lop/rop node which has everything necessary in an artist friendly manner (including AOV selection, proper handling of renderproduct/rendersettings etc when it comes to all of this (it also goes hand in hand with quite a lot of aspects) - I've added controls for color management in it as well + fixed resolution handling correctly - the generic render settings node has quite a lot of deprecated settings exposed, I have already finished the demo - will send it out soon)

I also made some occasional redesign e.g. exposed native moonray spoltight controls - which was overriding the usd light into the native one since it just had so much more extended controls in comparison with USDLuxShaping ones.

And I think that I noticed some push recently which was focused on exposing execution modes which I'd like to give a try to as well - a try to means exposing them in a friendly matter - native rop/lop.

I'll continue this wth a couple of PRs. I've just made one (not so massive one) with h22 build on top of the latest releases/PRs, I'll dissect it into the smaller pieces. Got a decent grasp of what to touch & where from the massive PR, so I'd be able to keep it clinical.