Storage class for cooperative matrix.

The cooperative matrix spec states the following:
a. Under overview, we have: "cooperative matrix" types, where the storage for and computations performed on the matrix are spread across a set of invocations such as a subgroup.
b. Under validation rules, we have: Cooperative matrix types (or types containing them) can only be allocated in Function or Private storage classes.

It is a bit confusing as the Function / Private storage classes are not spread across a set of invocations.

A request for clarifying this was raised in https://gitlab.khronos.org/spirv/SPIR-V/-/issues/824 and it was suggested there that this can be a topic for SPIRV-Guide.

Clarification: The idea here is coopMat types in the program are referred to be in Function / Private storage whereas the underlying type that supports coopMat type can be in a storage other than Function / Private like Workgroup storage class. It also depends on multiple mental models that work out for coopMats.

Start by reading the cooperative matrix specification and the linked SPIR-V issue #824. Clarify how Function and Private storage classes relate to cooperative matrix types while the underlying supporting type may use another storage class, including the relevant mental models. Done means the SPIRV-Guide explanation resolves the apparent conflict.

Written by the indexing model from the issue text.