profileGeometryType vs. profileGeometry2DType

[jnwalther]

As mentioned in #780, there seem to be some things, that need clarification w.r.t. profileGeometryType and profileGeometry2DType and what exactly is the purpose for each.

Let's take a look at the current situation:
The profileGeometryType is currently being used by fuselageProfile, rotorAirfoil and wingAirfoil. Historically it provides a pointList of curvePointListXYZType, i.e. a list of 3D points. As far as I am aware, one of the dimensions is always filled with zeroes. Thus we have in fact always a 2D profile, which is only given in 3D in order to allow for unambiguous 3D transformations down the line.
However, more recently, we have also added the cst2D and standardProfiles nodes, which only provide parameters to describe a profile in 2D. As such, there is no way to tell how the profile is aligned in 3D, which undermines the whole point of having a 3D point list as stated previously.

To make matters worse, there is an additional profileGeometry2DType, referenced by curveProfile and nacelleProfile, which once again provides a pointList node, this time of pointListXYVectorType. We also have the cst2D node once more, which references the cst2DType (exactly like in profileGeometry). The standardProfiles node is missing.

This is both confusing and inconsistent, so we should consider the following changes:

• We postulate, that a profile, by nature, is flat, i.e. 2D. If it's not flat, it's not a profile but a curve.
• This means we only need one type, which for simplicity should be profileGeometryType
• In this node we provide a 2D definition using CST, standard profiles, or a to be created curvePointListXYType (or we go all out and also add all profile types from OpenVSP).
• (Personally, I don't see a particular reason why the rectangle and superellipse need to be separated from cst and curve interpolation, so I would also dissolve the standard profiles node and just add them to the list of choices in profileGeometryType)
• To ensure we can provide the 3D alignment information, previously conveyed by the zero dimension of the curvePointListXYZType, we introduce an additional optional node e.g. axes3D, where we can specify the 3D axes corresponding to the local x and y axes e.g. 'xy', 'xz' or 'zy'. This will allow us to encode the information to reorder the coordinates and introduce the zero dimension as needed in a more efficient manner.

@MarAlder, @joergbrech, @AntonReiswich, @rainman110, @CLiersch, @ChristianHesse, please let me know what you think.

[jnwalther]

Here is a diagram of an updated profileGeometryType definition for illustration: