IfcMatrix as generalization of rectangular lists-of-lists

**Description of the proposal:**
@aothms and I were chatting about the challenges of mapping EXPRESS list-of-lists types to/from UML (e.g., the control point list in [IfcBSplineSurface](https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/schema/ifcgeometryresource/lexical/ifcbsplinesurface.htm)). I've also run into this problem in writing ANTLR parsers for IFC-STP. To reduce dependence on Part 21-specific semantics and improve the consistency of the IFC data model, why not define a new Entity type, **_IfcMatrix_**, that _allows for the definition of rectangular matrices of arbitrary but finite degree_? It would replace (possibly nested) Lists in IFC parameters instead with a reference to an IfcMatrix that contains its contents.

At minimum, IfcMatrix would have three attributes:
- a list, _Values_, of all the values in the matrix in row-major order
- a list, _Dimensions_, capturing the size of each dimension
- a type annotation, _EntryType_. All entries in the matrix must be of the same Ifc class or type.
- ...with the constraint that the product of all Dimension values must equal the size of Values

This would work like numpy or APL's [reshape](http://microapl.com/apl_help/ch_020_020_470.htm) operator. It might also be a compact way of serializing sensor data, point clouds, or basic linear algebra transformations.

**Describe how it contributes to the [objectives](https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC):**

List-of-list semantics are part of ISO 10303. If instead we make provisions for nested (rectangular) lists part of the IFC data model, the schema becomes more self-describing.

**Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one):**
_Add_

**What do we win:**
The ability to define matrices of arbitrary (finite) degree containing one type of IFC value. This can be used for lists, nested lists, matrix transformations, sensor data, or point clouds, depending on the use case. It also reduces dependency on ISO 10303-specific semantics.

**What do we lose**
This approach doesn't resolve cases with lists-of-lists are used to capture non-rectangular data. How many of examples of that are there in the schema? Where are they?

**Schema impact:**
Parameter type change for all IFC classes using nested-lists. Optionally, we could replace ISO-10303 lists too.

**Instance model impact:**
Serializers would need to rewrite nested lists as IfcMatrix instances. Propose we write a small stub service that does this conversion automatically for existing IFC instance populations to give vendors more time to make necessary changes.

**Backwards compatible:**
No.

**Automatic migration possible:**
I think so. We can detect - in both the schema and the instances - any presence of a (nested) list. If we can guarantee those lists are always rectangular, we can write a tool to automatically generate the equivalent IfcMatrix. Because no data is lost, the migration is reversible too.

---
Note that not all points need to be satisfied!
Backwards compatibility and file size are not concerns.

Start with the IfcBSplineSurface control-point example and review how nested lists are represented in the IFC schema and IFC-STP serializers. Identify rectangular versus non-rectangular cases, then define the schema, instance-model, and migration implications needed for an agreed IfcMatrix proposal.

Written by the indexing model from the issue text.