Extend stochastic texturing to anisotropic

[lgritz]

Recently, we added the ability to do stochastic sampling in texture
lookups, by choosing the MIP level stochastically rather than reading
two MIP levels and mixing them.

This PR adds the ability to also stochastically sample the anisotropic
filter footprint -- instead of multiple anisotropic samples, choose
just one sample well distributed over the footprint axis. On real
scenes, this seems to speed up overall rendering (not just texture) by
up to 2-3%, for scenes where average anisotropy is around 3-4.

It's much less dramatic a speedup than the stochastic MIP selection,
which sped up texturing by around 40% and in practice sped up overall
rendering by around 15% for us. Why doesn't cutting the number of
texture samples by another factor of 3 only speed up by 3% instead of
another 20%? Basically, it's because the stochastic MIP mapping by
definition means that each texture call touches half the number of
tiles as before. In contrast, those multiple probes along the
anisotropic axis are almost always within the same tile, and
frequently touch a very nearby pixel within the tile, so not only are
we not needing to look up a new tile from the tile cache, but also the
very memory we need to read is highly likely to be in L1$. But still,
we'll take 2-3% rendering gain any time we can get it, that's
equivalent to a lot of money if you have a really large compute farm.

Some other changes that come along for the ride:

Add a --bluenoise option to testtex (makes for prettier 1spp results),
and add tests for the aniso sampling.

Some internals changes to precompute min w,h of mip levels so there is
less per-texture-call rifling through the ImageSpec of each MIP level.
Sadly, this did not produce any consistently detectable speedup in
overall rendering.

And I changed the interface for stochastic texturing a bit. The old
way involved asking for new MIP modes, StochasticAniso or
StochasticTrilinear, in addition to being sure to set TextureOpt::rnd
to the stratified random number you are using for sampling. Now we are
deprecating StochasticAniso and StochasticTrilinear. Just use the same
old mip levels you always did. So the new interface can be summarized
as follows:

• On each texture call, setting opt.rnd >= 0.0f is itself a request for
  stochastic texturing on that call (opt.rnd will default to -1.0, and
  any negative value does the old fashioned non-stochastic filtering).

• A ShaderSystem-wide option "stochastic" (int) indicates which things
  should be sampled stochastically, for those lookups that have rnd >= 0.
  It's a bit field: 0 means no stochastic sampling (even if rnd >= 0),
  1 means to do stochastic MIP level selection 2 means to do stochastic
  anisotropic sampling (so 3 means to do both, and higher bits are reserved
  for future extensions). The default is 0, so renderers need to enable
  it to get any stochastic texturing.

Finally, let me give a reminder that you ONLY want to do stochastic
texturing for shading that involves multiple stochastic samples per
pixel, like orinary surface shades. For displacement (shade once per
mesh vertex) or "imager" (shade once per pixel), you just have a
single shade that you want perfectly filtered, so you probably don't
want to set opt.rnd >= 0 in those cases.