Refactor "meta" decls for stdlib texture types (shader-slang#2932)

We use some ad-hoc "template engine" code generation / metaprogramming
to generate many of the declarations in the Slang standard library.
In many cases the level of meta-ness is (relatively) manageable, but
one of the biggest tangles in the whole thing is the generation of
the texture-related types. We basically have a single set of nested
`for` loops that generate all types of the form:

    (RW|RasterizerOrdered|/**/)(Texture|Sampler)(1D|2D|...)Array?MS?

Inside that loop we then have tons of conditional logic to determine:

* Which points in the cross-product space should be skipped, rather
  than emitted as a type.

* Which methods to emit, or not.

* The type signature(s) of those methods.

* The translation of those methods for each target (via
  `__target_intrinsic`)

The code ends up being long, complicated, and very hard to maintain
or extend.

This change takes a first small step to try to help us get the
complexity more under control. The basic approach is that the data that
defines each point in the cross-product space is aggregated into a
`TextureTypeInfo` structure in the meta-level code, and then the logic
for emitting the declarations related to a given texture type is
expressed as a member function of that type.

The intention is that this design will more easily allow the meta-level
code to be factored into distinct subroutines, and enable us to clean
up and re-use recurring bits of text that need to appear in the output.

It is possible (though I am not yet predicting it) that we will end
up wanting to utilize a bit of an inheritance hierarchy on
`TextureTypeInfo` to allow us to more cleanly factor out code that
is specific to certain cases (e.g., there is only a small amount of
sharing between `RW`/`RasterizerOrdered` and read-only texture types).

It is intentional that this step introduces no significant changes to
the logic that used to be inside the loop (and is now inside of a
method). Instead, the goal is to minimize the scale of the diffs that
reviewers might be expectecd to deal with in follow-on changes.

Co-authored-by: Yong He <yonghe@outlook.com>

Author: tangent-vector