Removing LISTS of LISTS from schema

Description of the proposal:

There are several cases in IFC (11 specifically in IFC4x3 by my count) of schema attributes that declare LISTS of LISTS. Most of these relate to geometry and share a similar flavor:

- `ControlPointsList : LIST [2:?] OF LIST [2:?] OF IfcCartesianPoint;` on `IfcBSplineSurface`
- `CoordList : LIST [1:?] OF LIST [2:2] OF IfcLengthMeasure;` on `IfcCartesianPointList2D`
- `CoordList : LIST [1:?] OF LIST [3:3] OF IfcLengthMeasure;` on `IfcCartesianPointList3D`
- `ColourList : LIST [1:?] OF LIST [3:3] OF IfcNormalisedRatioMeasure;` on `IfcColourRgbList`
- `InnerCoordIndices : LIST [1:?] OF LIST [3:?] OF UNIQUE IfcPositiveInteger;` on `IfcIndexedPolygonalFaceWithVoids`
- `TexCoordIndex : OPTIONAL LIST [1:?] OF LIST [3:3] OF IfcPositiveInteger;` on `IfcIndexedTriangleTextureMap`
- `WeightsData : LIST [2:?] OF LIST [2:?] OF IfcReal;` on `IfcRationalBSplineSurfaceWithKnots`
- `InnerTexCoordIndices : LIST [1:?] OF LIST [3:?] OF UNIQUE IfcPositiveInteger;` on `IfcTextureCoordinateIndicesWithVoids`
- `TexCoordsList : LIST [1:?] OF LIST [2:2] OF IfcParameterValue;` on `IfcTextureVertexList`
- `OPTIONAL LIST [1:?] OF LIST [3:3] OF IfcParameterValue;` on `IfcTriangulatedFaceSet`
- `CoordIndex : LIST [1:?] OF LIST [3:3] OF IfcPositiveInteger;` on `IfcTriangulatedFaceSet`

Despite IFC providing a deep and comprehensive type system, these nested LISTs seem to strip away semantic intent. Two concrete examples:
- Despite IFC defining a dedicated `IfcCartesianPoint` entity, whose members are `IfcLengthMeasure`, we're instead redeclaring a similar definition as `LIST [2:2] OF IfcLengthMeasure` in `IfcCartesianPointList2D`. Why not define `IfcCartesianPointList2D` in terms of a `LIST OF [1:?] IfcCartesianPoint2D`?
- Despite IFC defining a dedicated `IfcColourRgb` entity, whose members are `IfcNormalisedRatioMeasure`, we're instead redeclaring a similar definition as `LIST [3:3] OF IfcNormalisedRatioMeasure;` in `IfcColourRgbList`. Why not define `IfcColourRgbList` as `LIST [1:?] OF IfcColourRgb`?

The other examples are similar, and removal of the nested lists increases model cohesion.

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

By removing all occurrences of nested lists, all multi-valued attributes become single-level lists or sets, which simplifies encoding and transformation across technology backends.

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

What do we win: consistency, cohesion, simplified integration patterns.

What do we lose: Software vendors would need to update their processing code for these types. Increase in file size.

Schema impact: Likely introduction of several new TYPEs, and removal of all nested LISTS.

Instance model impact: All nested lists replaced with single-level lists or sets of ENTITY or TYPE instances.

Backwards compatible: No.

Automatic migration possible: Yes.

Additional implications:

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