Allow subsurface_radius_scale to go above 1

[peterkutz]

This PR removes the upper bound on the supported range of values for subsurface_radius_scale. This lets this parameter be used to decrease the volume density, not just increase it.

[virtualzavie]

LGTM

[AdrienHerubel]

Should this change target a fix or a feature branch ? And is not that redundant with subsurface_radius ?

[jamportz]

I'm not sure I'm comfortable with the idea of this PR. Currently the subsurface_radius is supposed to define the length scale of the mean free path, with the subsurface_radius_scale applying a per-channel modulation to this. The color which is entered is similar, though not identical, to the color seen in thin areas which transmit.

It seems a bit unintuitive to allow for arbitrarily high HDR color components, since then the resulting "color" will generally have no relation to the color seen in the render. It's also redundant with the current functionality, and doesn't seem much of a convenience.

[najibna]

The range lift to $[0, \infty)^3$ with a Norm of $[0, 1]^3is consistent betweenindex.htmlandparametrization.md.html`, and keeping the Rayleigh default is reasonable.

This does not touch reference/open_pbr_surface.mtlx, which still hard-caps subsurface_radius_scale at uimax="1,1,1". If values above 1 are now legal, that UI max will hide them.