Make sure interactive modification of the scene doesn't crash Cycles

[boberfly]

Live edits to the Gaffer scene seems to work with Cycles to an extent, but there might be some small issues still where Cycles may crash in certain combinations of scene modification. This is a global bug issue ticket to keep an eye on this.

Blender's scene conversion implementation seems to just wipe everything and start again on some scene modifications which we can do better here, but this will need to be looked at carefully (eg. re-create mesh BVH structure only when the BVH settings change, and not re-create the mesh conversion if it isn't needed).

Also keep an eye on any race conditions by converting to Cycles objects in multiple threads. We are using TBB's concurrent hashmap as a cache like the other backends in Gaffer, and making a spinlock on a std::vector for objects which aren't instanced and don't need a hashmap like lights. We should be faster than Blender here as I think this is single-threaded conversion for them, so some code paths might not be tested very well in Cycles if we do this on multiple threads.

[boberfly]

c70e243

This commit solves some of the crashing when you play around with the shader networks while rendering in interactive mode, and will revert to a fallback 'facing ratio' shader if there's no shader assigned, much like the other renderers in Gaffer do.

[boberfly]

adbafc4

This commit makes it so the catalogue doesn't make a new image at every scene change

[boberfly]

9c49c4d

This fixes quite a few runtime bugs

[boberfly]

87ebded

This also fixes quite a few things with the session/scene options being changed in a live render

[boberfly]

4ca9185

Using Cycles' scene object to set mutex locks/unlocks when doing scene modifications. Might need to revisit this and see if I need to make 'try locks' instead.

[boberfly]

https://github.com/boberfly/GafferCycles/releases/tag/0.13.0 stabilises things greatly with a mutex lock over the scene in the render function, and shaders get deferred now so they don't crash.

I think that almost-unreasonable changes like BVH/device or between SVM/OSL shader backends may crash things, so I will leave this open and push the milestone to post-1.0.