Hue Saturation Value Node for Cycles

conversion of HSV Node to Cycles

OSL:
----
I moved the rgb_to_hsv and hsv_to_rgb out of the node_mix.osl to the node_color.h (where we have srgb/linear space functios).

Also, I had to change the variables name (in relation to the nodes.cpp). Because there are two variables named Color. Since I can't build OSL, I couldn't really test if the arguments will be parsed by order or by the name.

SVM:
----
I moved the rgb... functions to the new svm_hsv.h.
I think that it makes more sense to be there than to be in the svm_mix.h
It can be moved to a new svm_color.h if you think it's better.

Other:
-----
I'm using fmod instead of the manual operation we have in the blender render node:
hsv[0] += hue - 0.5; if hsv[0] < 0: hsv[0] -= 1.0;  if hsv[0] > 1: hsv[0] += 1.0

I don't know if fmod is faster or not though.

Also, Hue, Saturation and Value can be calculated separated. So in theory this node could be broke in 3 nodes that could run in parallel.
I don't know if the code would take advantage of this though (or if the overhead would make it worse). And I'm not sure if we actually get multithreading when having multiple nodes (I think not, but that may be another way).

[brechtvl, 2011-12-02 14:13:19]

LGTM. fmod is more correct if you get values further away from 0/1. Regarding
multithreading, that doesn't matter here, all threads render different pixels,
the node graph is evaluated entirely by one thread always.