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
    ...
ShadingSystem: Add group-specific attribute()

I don't have a use for this at the moment, but I anticipate some (and
it's symmetric to the group-specific getattribute I already added), so I
want to get the function added before the next major version branch.
Enhanced constant folding of format().

Because the general case is a PITA, we had been tackling it on a case-by-case
basis, and in fact previously only folded the "%s" case. Extend this to
constant fold "%d", "%s%d", "%s%s", "%d%d", and "%s%d%d" cases.
Enhanced simplification of compassign, mxcompassign, and aassign.

Consider this idiom:
    color C;
    C[0] = 3.14;
    C[1] = 0;
    C[2] = 42.0;

We track constant-ness by whole-symbol, not by individual component of
aggregates (like colors or points or arrays). So previously, this code
would result in element-by-element assignment of the color, which even
then would not be recognized as a constant.

(N.B. That looks like silly code compared to "C = color(3.14,0,42)", but
in fact people do this kind of nonsense, and even if they didn't, they
might be assigning *non-constant* things that, only part way through
optimization, are all turned into constants.)

With this patch, we recognize consecutive component assignment to the
same aggregate, and if ALL components get assigned constants, we can
replace the whole code sequence with just a single assignment from a
constant aggregate, which in all likelihood will lead to the later
elision of the variable altogether.

This applies to compassign (component assignment to triples),
mxcompassign (component assignment to matrices), and aassign (individual
element assignment to arrays).
More enhanced constant folding of format()

Instead of a small number of specific cased ("%s", "%s%d", etc.), now
we loop over the arguments, back to front, peeling each one off and
formatting it into the format string itself, until there are no more
constant-valued arguments at the end. If we've exhaused all arguments by
the time we're done, the format goes away entirely and we just have a
string assignment.

To illustrate,
    format ("%s %g (%g)", "blah", 42.0, point(1,2,3))
turns into the constant string "blah 42 (1 2 3)", and
    format ("%s %g (%g)", "blah", u, point(1,2,3))
would at least simplify to
    format ("%s %g (1 2 3)", "blah", u)

Most of the interesting cases are the first category (complete formatting),
but at least in the partial-formatting case it's a little bit simpler.
Fix bug when double-specifying a shader parameter and restoring to original
When resetting valuesource to default, also make sure to copy the default value back into the parameter's storage