Add convenient constructor for Torus

[SebastianRuffert]

No description provided.

[fhagemann]

It might also make sense to allow φ to be a Tuple and do the conversion to a T in the constructor (see #240).
Or to generally allow for the same keywords as we do when parsing a dictionary from a config file (?)

[lmh91]

I just realized that we have two rotations in the constructor due to φ.
The order how they are applied is important.
I think we did not specified that in the documentation so far, did we?

rotation * RotZ(φ[1]) != RotZ(φ[1]) * rotation is the "issue".

We will have to decide for one and stick to it for all primitives and have to state it in the documentation.

Any opinions on which order is the better one? In sense of that it is easier to construct certain geometries.

[SebastianRuffert]

I just realized that we have two rotations in the constructor due to φ. The order how they are applied is important. I think we did not specified that in the documentation so far, did we?

rotation * RotZ(φ[1]) != RotZ(φ[1]) * rotation is the "issue".

We will have to decide for one and stick to it for all primitives and have to state it in the documentation.

Any opinions on which order is the better one? In sense of that it is easier to construct certain geometries.

I think we should stick to rotation*RotZ(φ[1]). The user wants to construct a specific geometry ranging from one polar angle to the other one, afterwards he rotates it. Thus this order.

[lmh91]

I just realized that we have two rotations in the constructor due to φ. The order how they are applied is important. I think we did not specified that in the documentation so far, did we?
rotation * RotZ(φ[1]) != RotZ(φ[1]) * rotation is the "issue".
We will have to decide for one and stick to it for all primitives and have to state it in the documentation.
Any opinions on which order is the better one? In sense of that it is easier to construct certain geometries.

I think we should stick to rotation*RotZ(φ[1]). The user wants to construct a specific geometry ranging from one polar angle to the other one, afterwards he rotates it. Thus this order.

Sounds reasonable.
Could please make a note into the documentation in /docs/src/man/csg.md?
Maybe under ### Combination of Transformation?

With some example maybe? Or extend the example of the tube by adding also some limitation in phi?

[lmh91]

I don't think that works.
One has to use the from-to syntax in the configuration files.

I think this note here should be enough:

!!! note
    If $\varphi$ is specified for a certain interval, the interval is internally converted into a rotation, $R_{\varphi}$, of the primitive.
    This rotation is applied prior to the rotation specified in the rotation field, $R$. 
    Thus, internally, both rotations are calculated into the final rotation matrix of the primitive, $R_f$, via $R_f = R \cdot R_{\varphi}$.    

Could you please add this unter the Rotation section
and just delete this part. I think the above note is enough.