CHANGES and docs update, bump version
Fix ref image after recent microfacet change
Fix warnings about local variables written but not read
Fix potential debug printing crash if group name is NULL
actually by simplifying some prints to use the ustring directly,
which is also less verbose.
Add Boost version 1.55 in CMake build
Constant folding of compassign and mxassign
Triple component set for cases where the previous value is known (in
addition to the index and assigned value are constant).  Turn A[I]=C
into A=N, where N=A but with N[I]=C.  Same for matrix component assigns.

A practical example of this would be the following code:
    color C = 0;
    C[1] = 0.5;
Now it will turn this into a constant (0, 0.5, 0) instead of assigning
to C and then assigning one component of C separately.
Fix IlmBase 2.1 build breakages
(other minor changes are due to syncing with the analogous file in OIIO)
Change some pass-by-value to pass-by-ref, very slight but measurable speedup
Remove remnants of hash() from the OSL spec and type checking.
It was never implemented, and we can't think of a good use for it.
Use string_view for most public API input parameters
Bump version after API change, update CHANGES and rebuild PDF docs.
Improve error message
Change Symbol::name() from returning a const ustring& to just a ustring.
Work towards allowing queries of interesting post-optimization information.

Extend the ShadingSystem API to allow a form of getattribute() that
takes the pointer to a specific ShadingGroup. Some possible queries are
about post-optimized state, in which case asking for them will trigger
optimization on that group if it has not yet been performed.

We start out with two sets of interesting group attribute queries (and,
of course, the infrastructure and code by which we record them):

1. Make it possible to extract the names of all textures that it can
determine might be accessed by the group (after all instance value
binding, constant folding, and optimization has been taken into
account), as well as knowing whether additional textures may be
accessed, whose names cannot be determined without actually executing
the shader. (This may be helpful to renderer implementations that simply
are not able to accommodate textures that can't be bound prior to
start of shader execution.)

2. Make it possible to extract the names and types of all "user data"
that might be queried (that is, shader parameters that may, after
optimization, still be expected to take on per-point interpolated
values, supplied by the geometry). (N.B. This is leading toward another
really interesting feature/optimization, which will be part of a later
checkin.)

See testshade.cpp, test_group_attributes(), for examples of these
queries in action.
De-virtualize OSLCompiler and ShadingSystem classes!

There are two ways to expose just an abstract class API from a library,
while completely hiding all internals of the class (and in particular,
data internals).

1. Subclassing: Make the Foo public API be an abstract class, with only
pure virtual methods, and no data. Internal to the library, subclass the
parent as 'class FooImpl : public Foo', fully elaborating the
methods. This implementation class is hidden from the client app, so
you'll need create() and destroy() methods.

2. PIMPL idiom: Make the Foo public API a simple concrete class with no
virtual methods, but containing a private FooImpl *m_impl (where FooImpl
is a forward-declared class, so not exposed). The ctr/dtr of the exposed
class will internally create/destroy a FooImpl, and all the methods of
Foo::method() simply call m_impl->method().  This means that the FooImpl
also now no longer needs any virtual methods.

The cost of these are roughly the same -- #1 needs to look up methods in
the vtbl every time, whereas #2 needs to make an extra wrapping function
call every time (though in theory, a good optimizing compiler with LTO
should be able to make this essentially free).

If it's important for the client app to be able to completely substitute
their own custom implementation while following the same API (i.e.,
somebody needs to subclass Foo to specialize it), then #1 is the only
way to go. An example of this is RendererServices -- the whole point of
RS is to allow a renderer implementation to subclass it in order to
provide all the renderer-specific bits of functionality.

However, if the library is providing the one and only possible
implementation, i.e., no subclassing is ever desired/necessary, and the
whole exercise is simply to hide the implementation details behind an
abstrat API, then #2 has a distinct advantage: because there are no
virtual methods, Foo can have new (non-virtual!) public methods added,
and FooImpl can change arbitrarily, without breaking backward
compatibility in linkage with apps! In other words, #2 allows
substantially more change to internals, and adding publicly exposed
features, without violating promises that are usually made about
compatibility for "release branches" of a product. (Whereas, the #1
approach dare not change anything about the API, for fear of altering
the layout of the vtbl.)

So, therefore, this patch "de-virtualizes" the main two public
interfaces for OSL, OSLCompiler and ShadingSystem, switching their API
abstraction strategy from approach #1 to approach #2, and thus serves as
powerful insurance as we move forward, allowing much more freedom in the
range of changes we make may to internals within release branches
without breaking compatibility.
Revise getattribute userdata retrieval

Instead of copying the whole array to user space (especially awkwardly
for the userdata_types, since there is no way for TypeDesc to specify
a TypeDesc type!), I changed it so that they are actually retrieving
a pointer.  So it looks like this:

    ustring *names = NULL;
    shadingsys->getattribute (group, "userdata_names",
                              TypeDesc::PTR, &names);
    // now names[0] is the first name, names[1] the second, etc.

This is safer and simpler, and doesn't require coping or allocation, since
the names and types already exist in the group as a contiguous array.

Also, I added one more tag, "userdata_offsets". Suffice it to say that
in a future checking, it will all be clear how and why it's used.
Make testshade multithreaded, and other testshade/testrender cleanup
ShadingSystem methods to retrieve the texturesys and renderer
testshade/testrender - print tex sys, IC, and ustring stats
when in debug or stats mode.
OSL statistics output includes version and major options.

This is so that when viewing a log containing OSL ShadingSystem
statistics, we can be sure which version of the library it was, and how
the most important options were set.

Example output looks like this:

    OSL ShadingSystem statistics (0x7ff65c005a00) ver 1.5.7dev
      Options:  optimize=2 llvm_optimize=0 debug=1 llvm_debug=0 lazylayers
                lockgeom_default range_checking
      Shaders:
        Requested: 1
    ...