Remove IfcPreDefinedPropertySet and convert into a Pset

[Moult]

Description of the proposal:

Remove IfcPreDefinedPropertySet and all of its subclasses. Instead convert them to Psets just like all other Psets. In fact, even the documentation suggests extending them using psets, so it seems like a easy decision :) Here's a first pass:

• IfcDoorLiningProperties -> Pset_DoorLining (applies to IfcDoor)
• IfcDoorPanelProperties -> Pset_DoorPanel (applies to IfcDoor)
• IfcPermeableCoveringProperties -> Pset_PermeableCovering (applies to IfcDoor, IfcWindow, IfcAirTerminal)
• IfcReinforcementDefinitionProperties -> Pset_Reinforcement (applies to the same stuff as concrete psets)
• IfcWindowLiningProperties ->Pset_WindowLining (applies to IfcWindow)
• IfcWindowPanelProperties -> Pset_WindowPanel (applies to IfcWindow)

Note: this is similar to #15 - but whereas #15 talks about attributes, this one is a "easy win" since it talks only about IfcPreDefinedPropertySet.

Also, I think door lining and window lining can be merged into lining... but let's not complicate things :)

Relevant forum thread since September 2019: https://forums.buildingsmart.org/t/why-are-door-and-window-attributes-special/1866

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

What do we win:

Simpler spec:

• No special edge case for doors and windows and ... reinforcement?
• Less classes to parse
• More version stability as these things tend to change more than regular Ifc classes

What do we loose <-- fix typo!

Really nothing.

Schema impact:

Good impact.

Instance model impact:

?

Backwards compatible:

No

Automatic migration possible:

Yes. Easy.

Additional implications:

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