Conflicting door definitions

[jnwalther]

As presented during yesterday’s stakeholder meeting following @rmaierl’s remark in #492, a survey of the door definitions in CPACS has shown three conflicting ways to define door geometry.

• Using the door definition in the fuselage/decks node
• Using the paxDoor/cargoDoor definition in the fuselage/structure node
• Using the cutout definition in the fuselage/cutouts node

Our proposal (and the way it has been implemented in the new deck definition #674) is to make the cutout definition the ground truth for door geometry definition, which is referenced by the deckDoors node to add context on utilization, evacuation capacities etc. The structural doors node (merge of paxDoors and cargoDoors) also references the cutout, but is used to store structural context e.g. surrounding primary structure elements. As a consequence, the door and doorSurroundStructure definitions in the structuralElements node will be also be deprecated as agreed in the stakeholder meeting.

Furthermore, it is proposed to generalize the definition of the cutout profiles to profileGeometryType (the current definition reimplements the rectangular standard profile).

@ChristianHesse and I would be prepared to compile these requirements into an updated schema, unless there are major concerns from key stakeholders.