Extend 'len' attribute for nested pointers

[mematthias]

This draft PR experiments with an extended len syntax for pointer-to-pointer parameters in the KHR acceleration structure build commands.

The goal is to describe the conceptual 2D shape of these parameters more accurately:

• outer dimension: infoCount
• inner dimension: pInfos[i].geometryCount

This syntax is new for the Registry and is proposed here only as a draft for discussion.

Proposed constraints for the new len form

The extended len="X,Y" form (with Y referencing SomeArray[].member) is intended to be valid only under the following conditions:

1. The referenced symbol in Y (e.g. pInfos) must be another member of the same command/struct/union.
2. That member must be a pointer type (e.g. const VkAccelerationStructureBuildGeometryInfoKHR* pInfos).
3. The target pointer must itself have a len attribute whose first component matches the first component of the extended len (here: both use infoCount as the outer dimension).
4. The pointed-to type must be a struct that contains the referenced inner member (here: VkAccelerationStructureBuildGeometryInfoKHR must contain a geometryCount member).

These rules are intended to keep the semantics constrained and mechanically checkable for tools and schema validation.

[oddhack]

We'll need to check with downstream consumers to see how they handle this change. Often this sort of thing can be very slow to get in because downstreams not only don't know how to handle it, they can do the wrong thing on encountering it - but this follows existing syntax (if not semantics) for the attribute, and is limited to just a few places, so it's worth checking. Usually we ping the SDK folks (@spencer-lunarg), Vulkan-Hpp (@asuessenbach), and Ash (@MarijnS95) as those are the most important downstreams we know about.

Assuming the change is acceptable, at that point we'll need an addition to the schema document (registry.adoc) describing this new usage.

[MarijnS95]

Ash is already able to parse these existing ,1 suffixes. We would have to slightly adjust our parsing logic to ignore these C-like expressions, but we're (at least for now) unlikely to have a use for this.

---

Often this sort of thing can be very slow to get in because downstreams

Note that I removed Ash from all Khronos repositories' CI exactly to prevent this from being an issue.