PARAMS will be used as wildcards, OPTIONS will only be validated and used in the configuration

a centrilized definition of parameters is bringing complexity in the algorithm, that is not necessary. a better solution is to make the use of parameters more obvious and to make the code more readable

progress - squash this commit later

progress - squash this commit later

fix consistent use of angles in extract_geo_paras. using y-axis as reference for camber_angle as it is intended by the according test-function

fix beta_notation (old ntr notation). should we switch? in any case, make this documented via the profile-plot!