Implement state checkpointing for decision nodes

[arcondello]

Closes #510
Closes #552 by replacing it

AI Generation Disclosure

No AI was used to write the code. I intend to use it to review this PR.

[fastbodin]

A bit of a pain, but I think it might be worth adding a single test for BinaryNode with checkpointing to check that all the correct indices are cached with 1s and 0s (I am referring to the BinaryNode DisjointSparseSet).

THEN("Sum constraint sums, tracked indices, and state are correct") {
    CHECK(bnode_ptr->sum_constraints_lhs(state).size() == 1);
    CHECK(bnode_ptr->sum_constraints_lhs(state).data()[0].size() == 1);
    CHECK_THAT(bnode_ptr->sum_constraints_lhs(state)[0], RangeEquals({3}));
    check_indices<true>(state, bnode_ptr, 0, 0, {1, 2, 5}); // <- ***** This check is the important one ******
    check_indices<false>(state, bnode_ptr, 0, 0, {0, 3, 4}); // <- ***** And this one ******
    CHECK_THAT(bnode_ptr->view(state), RangeEquals(expected_init));
}

[arcondello]

It seems that BinaryNode::assign_checkpoint() is very broken because it has a different update method. I think we need to refactor the various state data classes to use virtual methods.

[arcondello]

I think I need to take another documentation pass. I'll try to do that today

[fastbodin]

Officially gone through everything. I need to look at the number.cpp and collections.cpp again. On the whole, looks good. Most of my comments above are clarifications. I will resolved them ASAP to avoid clogging the thread on this PR.

[fastbodin]

Testing my understanding. You mean

        // Right now, you can only revert to the most recent checkpoint. It's
        // pretty straightforward to support going further back, but this is all
        // we need right now.
        assert(this->checkpoint_ptr<NumberNodeCheckpoint_>() == checkpoint_ptr);

[fastbodin]

Nit: This doc string is good but omits some information. Possible alternative (that could be improved) based on my (possibly incorrect) understanding of drop.

// The current `drop` where `drop` is equal to the number of `Updates` 
// in the last `diff` cached by `updates_` that the checkpoint 
// is NOT responsible for tracking. Functionally, there are two cases. 
// 1. `drop == 0` and the checkpoint is responsible for all `Updates` 
//     stored in the last `diff` of `updates_`.
// 2. `drop > 0` and the checkpoint is *not* responsible for the last
//    `drop` number of `Updates` in the the last `diff` of `updates_`.

[fastbodin]

I just realized the above was in-fact, incorrect. Will try again.

[fastbodin]

Looking at this again, this is a bug. This does not take into account the running slice sums (should they be tracked). This was not caught in the tests because the relevant tests use exchange() which does not affect the running slice sums`.