Inline faces in IfcPolygonalFaceSet instead of an external IfcIndexedPolygonalFace

Description of the proposal:

Consider the following snippet - why can't the `IfcIndexedPolygonalFace` be in-lined (similar to `IfcCartesianPointList3D` into `IfcPolygonalFaceSet`? Wouldn't that be much, much more efficient?

```
#15=IFCINDEXEDPOLYGONALFACE((2,1,4,5));
#16=IFCINDEXEDPOLYGONALFACE((1,2,8,3));
#17=IFCINDEXEDPOLYGONALFACE((1,3,6,4));
#18=IFCINDEXEDPOLYGONALFACE((4,6,7,5));
#19=IFCINDEXEDPOLYGONALFACE((3,8,7,6));
#20=IFCINDEXEDPOLYGONALFACE((8,2,5,7));
#21=IFCCARTESIANPOINTLIST3D(((265.,4.,0.),(265.,6.,0.),(277.,4.,0.),(265.,4.,2.),(265.,6.,2.),(277.,4.,2.),(277.,6.,2.),(277.,6.,0.)));
#22=IFCPOLYGONALFACESET(#21,$,(#15,#16,#17,#18,#19,#20),$);
#23=IFCSHAPEREPRESENTATION(#10,'Body','Tessellation',(#22));
```

The proposal:

```
#21=IFCCARTESIANPOINTLIST3D(((265.,4.,0.),(265.,6.,0.),(277.,4.,0.),(265.,4.,2.),(265.,6.,2.),(277.,4.,2.),(277.,6.,2.),(277.,6.,0.)));
#22=IFCPOLYGONALFACESET(#21,$,((2,1,4,5),(1,2,8,3),(1,3,6,4),(4,6,7,5),(3,8,7,6),(8,2,5,7)),$);
#23=IFCSHAPEREPRESENTATION(#10,'Body','Tessellation',(#22));
```

The proposal is 58% of the original size in bytes.

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

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

What do we win: Files shrink to half their filesize otherwise.

What do we lose: nothing?

Schema impact: Change the data type of one of the attributes

Instance model impact: NA

Backwards compatible: No

Automatic migration possible: Yes

Additional implications: NA

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

Start with the IFC entity examples and the linked “Towards a technology-independent IFC” objectives. Review the proposed attribute type change, schema impact, backward compatibility, and automatic migration implications; the work is done when the schema change and its consequences have been resolved and documented.

Written by the indexing model from the issue text.