* Rename existing ParameterBlock to ParameterGroup

We are planning to add a new `ParameterBlock<T>` type, which maps to the notion of a "parameter block" as used in the Spire research work.
Unfortunately, the compiler codebase already uses the term `ParameterBlock` as catch-all to encompass all of HLSL `cbuffer`/`tbuffer` and GLSL `uniform`/`buffer`/`in`/`out` blocks (all of which are lexical `{}`-enclosed blocks that define parameters...).

This change instead renames all of the existing concepts over to `ParameterGroup`, which isn't an ideal name, but at least doesn't directly overlap the new terminology or any existing terminology.

The new `ParameterBlockType` case will probably be a subclass of `ParameterGroupType`, since it is a logical extension of the underlying concept.

* Add Shader Model 5.1 profiles

The HLSL `register(..., space0)` syntax is only allowed on "SM5.1" and later profiles (which is supported by the newer version of `d3dcompiler_47.dll` that comes with the Win10 SDK, but not the older version of `d3dcompiler_47.dll` - good luck figuring out which you have!).

This change adds those profiles to our master list of profiles, and nothing else.

* First pass at support for `ParameterBlock<T>`

- Add the type declaration in stdlib

- Add a special case of `ParameterGroupType` for parameter blocks

- Handle parameter blocks in type layout (currently handling them identically to constant buffers for now, which isn't going to be right in the long term)

- Add an IR pass that basically replaces `ParameterBlock<T>` with `T`
  - Eventually this should replace it with either `T` or `ConstantBuffer<T>`, depending on whether the layout that was computed required a constant buffer to hold any "free" uniforms

- Add first stab at an IR pass to "scalarize" global variables using aggregate types with resources inside.
  - This currently only applies to global variables, so it won't handle things passed through functions, or used as local variables
  - It also only supports cases where the references to the original variable are always references to its fields, and not the whole value itself

- Add a single test case that technically passes with this level of support, but probably isn't very representative of what we need from the feature

* Fold parameter-block desugaring into a more complete "type legalization" pass

The basic problem that was arising is that once you desugar `ParameterBlock<T>` into `T`, you then need todeal with splitting `T` into its constituent fields if it contains any resource types.
Handling those transformations by following the usual use-def chains wasn't really helping, because you might need systematic rewriting that can really only be handled bottom-up.

This change adds a new pass that is intended to perform multiple kinds of type "legalization" at once:

- It will turn `ParameterBlock<T>` into `T`
  - It may at some point also convert `ConstantBuffer<T>` into `T` as well
- It will turn an value of an aggregate type that contains resources into N different values (one per field)
  - As a result of this, it will also deal with AOS-to-SOA conversion of these types

Legalization is applied to *every* function/instruction/value, so that it can make large-scale changes that would be tough to manage with a work list.

This pass needs to be run *after* generics have been fully specialized, so that we know we are always dealing with fully concrete types, so that their legalization for a given target is completely known.

This is still work in progress; there's more to be done to get this working with all our test cases, and finish the remaining `ParameterBlock<T>` work.

* Improve binding/layout information when using parameter blocks

- When doing type layout for a parameter block, don't include the resources consumed by the element type in the resource usage for the parameter block
  - Note that this is pretty much identical to how a `ConstantBuffer<T>` does not report any `LayoutResourceKind::Uniform` usage, except that `ParameterBlock<T>` is *also* going to hide underlying texture/sampler reigster usage
  - The one exception here is that any nested items that use up entire `space`s or `set`s those need to be exposed in the resource usage of the parent (I don't have a test for this)

- When type legalization needs to scalarize things, it must propagate layout information down to the new leaf variables. In general, the register/index for a new leaf parameter should be the sum of the offsets for all of the parent variables along the "chain" from the original variable down to the leaf (we aren't dealing with arrays here just yet).

- When type legalization decides to eliminate a pointer(-like) type (e.g., desugar `ParameterBlock<T>` over to `T`), actually deal with that in terms of the `LegalVal`s created, so that we can know to turn a `load` into a no-op when applied to a value that got indirection removed.

- Hack up the "complex" parameter-block test so that it actually passes (the big hack here is that the HLSL baseline is using names that are generated by the IR, and are unlikely to be stable as we add/remove transformations).
  - Note: I can't make these be compute tests right now, because regsiter spaces/sets are a feature of D3D12/Vulkan, and our test runner isn't using those APIs.