Reconsidering the ability to allow class inheritance

I know this has been decided before, but the more I use IDS, but more I find it quite silly when people ask me "how do I write a requirement for all physical elements", the answer is: "copy paste from this big list of elements which only I have generated, and I've generated three variants of that list for IFC2X3, IFC4, and IFC4X3".

(and yes, people still copy paste wrongly)

And then when somebody reads the IDS, they see a massive list of objects and their eyes tend to glaze over.

In contrast, with inheritance and exclusion facets, I can express this in IfcOpenShell as simply as:

- `IfcElement, ! IfcFeatureElement` meaning all physical elements, minus openings and protrusions
- `IfcDistributionControlElement` meaning all the control elements in distribution system (no boring things like pipes and ducts and trays)
- `IfcSpatialStructureElement, ! IfcSpace` meaning stuff like sites, buildings, storeys (big things) except for individual spaces

It's simple, readable (to me at least), and works across schema versions.

Start by reviewing the earlier decision referenced in the issue and the nine-comment discussion, then compare the proposed inheritance and exclusion examples across IFC2X3, IFC4, and IFC4X3. Done would require an agreed IDS design for inheritance and exclusions, including clear behavior for the listed element categories and schema versions.

Written by the indexing model from the issue text.