Support proper 2D transformations

[hannobraun]

Fornjot supports both 2D and 3D shapes (sketches and solids). While the kernel is more nuanced about this, from the perspective of the CAD model, all those objects live in 3D space and can be transformed using 3D transforms.

It would be nice to add a bit of type safety, and only allow sketches to be transformed in 2D space, using 2D transforms. That would prevent unintended and possibly confusing mistakes, and also remove any ambiguity about what should happen, if a 3D-transformed sketch is to be exported to an external 2D-only file format.

I am not sure, if it should be possible to transform sketches in 3D space at all. I think this is definitely not needed right now, as the only use case I can think of is to prepare for a sweep operation. But the user could just as well sweep first, then 3D-transform the resulting 3D shape. Maybe there is a use case for 3D-transforming 2D objects once we support building shapes from b-rep primitives (which is currently a wishlist item).

[hannobraun]

Lots has changed since I opened this issue, and I'd like to update it. This remains a desired feature, and since we're probably not too far off from being able to sketch on surfaces (we already have a very clunky precursor to that functionality), it's also becoming more relevant.

I won't be tackling this for the time being, but in case anyone else wants to, here are some notes on how I would approach it:

• The current 3D transforms live in algorithms::transform, for legacy reasons. At some point, all transform code should be living in operations::transform.
• Unless someone moves the 3D stuff before this issue is being worked on, it probably makes sense to just create operations::transform as a 2D-only module, then subsume the 3D stuff afterwards.
• I think it would be a reasonable approach to just create new 2D traits (and implementations) based on what we currently have for 3D. Basically, that would mean adapting the current 3D traits for 2D, and adding 2D transform functionality to fj-math as required.
• However, I've been looking more into geometric algebra lately, and I suspect (but don't know for sure yet) that it might be better to approach the problem based on that branch of math. This is certainly where I would start, if I were to address this issue right now, and maybe some adventurous contributor would want to work on that too.

Hope that helps anyone who might be interested!

[hannobraun]

A note to anyone interested in tackling this, any work on this issue is likely going to collide with work on #2116 and #2118, which I'm planning to tackle soon. If anybody's interested, then feel free to tackle this. Just be aware, things are going to be in flux shortly, and there might be extra effort involved in doing this now, versus waiting until the dust has settled.

As always, please make sure to package any work into small and self-contained pull requests, to minimize the likelihood of merge conflicts with other ongoing work.