Unify full and partial objects

[hannobraun]

(This issue is part of a larger cleanup effort. See #1589.)

An object within the Fornjot kernel is a topological or geometric building block, like an edge or a vertex, for example. Together, these objects make up shapes. Objects are immutable and stored in an append-only data structure.

In addition to regular (full) objects, the Fornjot kernel has had the concept of partial objects for a while. This seemed to make sense initially, as more flexibility was required when building objects. For this reason, mutable partial objects were added, that could be used for building, then converted into full objects once done.

Since it was added, the partial object API has always been a bit of a problem point. Initially, it was extremely hard to use correctly, which resulted in lots of messy code. This problem was addressed eventually (#1249), but the solution left the partial object API in a state where partial objects are now very similar to full objects. There is even support for converting between them, in a way that retains the identity of the full object.

I have come to the conclusion that the existence of the partial object API can no longer be justified. It just adds redundancy and makes things more complicated. Both APIs should be unified into a single object API. I believe this will require one of two solutions to be implemented:

1. Make full objects mutable, so they can take over the role of partial objects. I already wrote down some thoughts (Future evolution of object storage #1454) on how this could be done.
2. Simplify the object graph to the point, where modifying it immutably becomes practical. I believe this will require the redundancy in the object graph to be reduced significantly, or even outright eliminated.

The latter solution is my favorite, as immutability would make the object graph easier to reason about, as well as make it easier to get insight into how shapes are being changed (see #1385). Plus, simplifying the object graph is a worthy goal in itself. If things worked out like that, it would just be the best situation overall. However, if it turns out that the object graph can not be simplified sufficiently, or that simplifying it is not enough to make immutable objects practical, solution 1 can be used as a fallback.

Work on simplifying the object graph is already ongoing (see some of the issues linked in #1589). I'm currently prioritizing work on the object graph this issue, as the results of that will inform the choice of solution here. But I don't see this issue as blocked, strictly speaking.

[hannobraun]

Work on this issue has been going very well, so far, as the long list of merged pull requests above this comment shows. It's been going better as expected, actually, and so far it looks like the more optimistic scenario, being able to keep all objects immutable, will come to pass.

I've been hitting the first non-trivial issue though, which revolves around how to update the objects that are referencing an updated object. This isn't rocket science, but there are details that I'm not clear on yet. This will require some more thinking.