SetFilter

This implements the SetFilter as required by #92.

The tricksy part about the SetFilter compared to the other existing filters is that it requires an input scene to compute the result. As discussed in #92, people expect to be able to plug the same filter into multiple nodes, and automatically have the appropriate input scene for each stream considered in each case. And they're not willing to manage input connections manually which seems fair enough. This leads us to a use of the Context I hadn't anticipated originally - when the FilteredSceneProcessor is pulling on the filter input, it places the input ScenePlug in the context too, so the filters can have access to it. This does make me slightly uneasy, as placing a plug in there is quite different to placing pure data, but it does work, and David and I felt it was preferable to any of the other solutions we'd considered. The only real consequence I can imagine at present is that it would now be harder to implement some sort of remote computation server, because a Context can't be serialised and sent afar in the same way as it could when it was pure data. But I don't think that was something that was going to happen soon anyway.

The path I took in implementing this is slightly winding, in that at one point there was basically a secondary filter context for passing the input scene. I did this just to get things rolling while I was tearing up the Context for optimisation and wasn't sure how it was going to turn out. In the end it turned out to be a fairly simple change and a good speedup so I felt it was best to just use the standard context for passing the input scene after all. If you feel it makes for a confusing history and a tough review, I could rebase it into fewer commits, but my guess was it's slightly easier to follow in the smaller chunks it's in at present...