Change the layout we compute/store for parameter groups (shader-slang#1540)

The type layouts we store for parameter group types (`ConstantBuffer<T>` and `ParameterBlock<T>`) has a somewhat complicated internal structure, which we've slowly built up and evolved as we learned more about what was actually needed:

* There is the outer `ParameterGroupTypeLayout` that represents the whole type (e.g., the `ParameterBlock<Something>`), and has resource usage/bindings based on what needs to be accounted for by anything (like a program) that uses the type. E.g., for a parameter block on Vulkan, the resource usage at this level would usually just be a single descriptor `set`.

* There is the inner "element" layout, which represents the layout for the `Something` in `ParameterBlock<Something>`. This was initially just stored as a type layout (and an extra type layout is stored for backwards compatibility), but we later realized we needed to store a `VarLayout` for the element, to deal with the fact that it might have a non-zero offset.

* Finally, there is the inner "container" layout, which represents the resource usage/bindings that are introduced by the block/buffer/group itself. In the case of a `ParameterBlock<Something>` this would include any "default" constant buffer that is needed in order to store the uniform/ordinary data from type `Something`. On targets like Vulkan and D3D12 such a buffer would no show up as part of the resource usage of the overall `ParameterBlock`, nor would it be expected to show as part of the "element" layout.

The above is just setting the stage so that we can cover the design choice that this change centers around: for each of the above layouts, what should the *type* stored with that layout be? The answers seem simple at first:

* The type for the outer `ParameterGroupTypeLayout` should clearly be the whole type (e.g., the `ParameterBlock<Something>`)

* The type for the inner "element" layout should clearly be the element type (e.g., the `Something` in `ParameterBlock<Something>`)

* The type for the inner "container" layout should be... hmm...

That last question is the thorny one. There are two main options, each with trade-offs:

1. What is being done in the code before this change is to store the whole type (e.g., `ParameterGroup<Something>`) as the type of the "container" layout. This makes some superficial sense (the type of the container should be a container type).

2. What this change switches to is the type of the "container" layout being null (it could equivalently be any sentinel that represents the absence of a meaningful type).

While option (1) seems like it would make sense, it risks creating an infinite regress for client application code. If they have a recursive routine that walks the Slang reflection hierarchy, then it will probably key off of the kind of each type it visits. Such a recursive walk would end up trying to treat the outer layout and the inner "container" layout equivalently, when they aren't really representing the same concepts. Even if it seems like this approach defendings against null-pointer crashes in client code, it really only delays them, since the inner "container" layout would yield a null type layout when asked for its element layout.

In contrast, option (2) more accurately reflects the reality that the container layout is a `VarLayout` and `TypeLayout` that correspond to no variable/type in practice. Clients of the Slang reflection API already have to deal with `VarLayout`s that have no variable, so it is reasonable for them to deal with `TypeLayout`s that have no type.

While the above statements may sound strange, it really comes down to the fact that a "type layout" is really just a way of encoding the "size" of something (where size can encapsulate all the different kinds of resources something can consume on our various targets), and a "variable layout" is really just a way of encoding the "offset" of something (again, where there can be different offsets per consumable resource).

In that light, it makes sense that the "container" layout for a parameter group is really just a way of representing the resource allocation of the container itself, and is not associated with any type or variable.

This change is technically a breaking change for clients of the reflection API, so it will need to be rolled out with an appropriate change to our version number.

Author: Tim Foley

source/slang/slang-type-layout.cpp

@@ -1969,8 +1969,23 @@ static RefPtr<TypeLayout> _createParameterGroupTypeLayout(
     // element type separately, and then combine these to form
     // the overall layout for the parameter group.
 
+    // Note: We leave the `type` field of the container type layout
+    // as null, because there is no available `Type*` that is suitable
+    // to put there.
+    //
+    // It might seem like we could use the `parameterGroupType` itself,
+    // since it is the logical "container," but doing so creates an
+    // unfortunate situation where we have a layout for a parameter
+    // group type that is not itself a `ParameterGroupTypeLayout`.
+    // Furthermore, it creates a nesting situation where a type layout
+    // for `parameterGroupType` contains a nested layout for `parameterGroupType`,
+    // and thus creates the impression of an infinite regress.
+    //
+    // The down-side to leaving a null pointer here is that it means
+    // we do *not* have an invariant that every `TypeLayout` has a non-null
+    // type, but that property is not explicitly useful/desirable.
+
     RefPtr<TypeLayout> containerTypeLayout = new TypeLayout();
-    containerTypeLayout->type = parameterGroupType;
     containerTypeLayout->rules = parameterGroupRules;
 
     // Because the container and element types will each be situated