Bug fix: optimizer interaction with output param that also is userdata

[lgritz]

There's a "pass-through parameter" idiom, where an output param gets
its initial value from an input, it gets modified by the shader, but
it's also an output.

If the modification is optimized away -- say, if it was originally
theparam *= scale and scale is 1 -- then it may be that you end up
with no ops in the shader that read from the parameter. If the
parameter was hooked up to userdata, then get_userdata will never be
called to retrieve the value (because it's usually lazy, only doing
the callback the first time it's needed), and so the output value of
parameter will be its parameter default value in the shader, NOT the
value of the interpolated variable, which was never retrieved and
copied into it.

This patch adjusts the logic somewhat so that if that output parameter
is connected downstream or is a renderer output, then we definitely
initialize it with a useparam op, even if it is otherwise apparently
not read from within the shader, and also that a shader consisting of
only that particular flavor of useparam is not marked as "does
nothing" (thus skipping any code generation at all).

Added a new test for this specific case.

Modified testshade to allow arbitrary command line-specificed userdata,
to make constructing this kind of test easier, by adding a --userdata
command which constructs a ParamValueList that will be used to look up
"userdata" from the shader.

Also necessitated update to reference output of debug_uninit test,
only because the extra useparam op caused some of the instruction
numbering to change.

[aconty]

LGTM!