adding some more mathematical shapes

[lzehl]

related to #186

[lzehl]

@xgui3783 and @apdavison before I continue here I would need your feedback.
Goal of these schemas are to define mathematical shapes without defining an actual coordinate space.

Which one do we most likely need ? How do we define them best / consistently ?

[xgui3783]

My immediate focus is that (IMO) all are 2D shapes, except sphere, which IMO is a 3D concept. Its 2D concept would be a circle.

I can Imagine circle used.

Would line segment also be included (or is it already included in a previous commit?)

Seems strange to not have rectangle, though one would argue that a rectangle is a special parallelogram. But the same can be said for square.

[lzehl]

@xgui3783 #186 has various 3D shapes besides sphere. But before I implement them I wanted to have feedback.

I would define a line as a coordinate point only within a given space. Therefore it is excluded here from mathematical shapes that are defined without a space. There will be another PR in connection with the annotation revision with a Contour schema (which can be a line).

Note that circle, rectangle and ellipse were already added to mathematical shapes in a previous PR.

[lzehl]

There can be more added (specifically for 3D) but I would like to clarify first if we want all of them for convenience or if we want to kick out all the ones that are theoretically covered by general classes.

Note: mathematical shapes should be space independent represented (since they are later to be placed an a coordinate framework). For this reason I avoided terms such as height, depth, etc (which also caused issues when defining 3D shapes as composites from 2D shapes).

[Raphael-Gazzotti]

General comment:
I am not sure all the specialized prism, pyramid, frustum shapes are necessary. We could define a general Prism/Pyramid/Frustum with a baseShape property using _embeddedTypes (e.g., Rectangle, Triangle, etc.). This would provide the same flexibility while avoiding multiple specialized prism/pyramid/frustum schemas. That said, specialized variants may still be justified if certain techniques or devices depend on explicitly defined shapes.

For the arrays of QuantitativeValue, it’s unclear whether the values are expected to follow a specific order (e.g., major and minor diameters for an ellipse). if ordering matters, this should be clearly specified in the instructions.