Option lazy_userdata causes lazy (on-demand) interpolation of userdata.

The previous behavior was that unconnected, lockgeom=0 parameters (those
that must be resolved by get_userdata to retrieve a potentially
interpolated value) are resolved up front in the shader, so that individual
uses of that parameter don't need to check or worry about whether the
interpolation already happened.

But consider this shader logic:

    if (condition)
        use userdata A
    else
        use userdata B

Any particular execution of the shader, we would hope, would interpolate
either A or B, but not both. But the existing behavior was to do the
interpolations up front, so both got interpolated. If a particular
renderer had a very expensive implementation of get_userdata, this could
be a performance issue.

With this patch, when the lazy_userdata option is set to nonzero, will
instead do it lazily -- calling get_userdata the first time it's needed
in execution of the shader.

I added a statistic that tracks the number of get_userdata calls made.
This definitely shows that when the new option is turned on, fewer
get_userdata calls happen in my production scenes, though the total
render time does not change enough to measure. But there is another
particular user of OSL in whose renderer the get_userdata is potentially
expensive, so we're hoping that this makes a noticable time difference
for them.

This is still off by default for the moment, giving the old behavior.
As I gain confidence that it's for sure correct and always speeds things
up (I can imagine cases where it is a performance penalty, but don't
know if that will happen enough in practice to matter), I may change the
default to be on.