fix(engine/deps): preserve definitions order whenever possible

[W95Psp]

In most of the backends, a top-level definition should come prior to it's use. This is not true in Rust.

Thus, we need to sort the items so that item a comes before it is used in another item b.

We used to do that with a topological sort with the ocamlgraph library. But since this topological sort operated on a graph, we were loosing the original order of items.

This commit now:

• construct a the transtive closure of the dependency graph
• use this closure to stable sort the items

The comparison function is defined as follows (g denotes the transitive closure):

1. if there is an edge a ⟶ b in g and an edge b ⟶ a, we are in a recursive bundle, hence we return 0: a equals b
2. if there is an edge a ⟶ b in g, we return -1
3. if there is an edge b ⟶ a in g, we return 1
4. otherwise there is no relation between a and b, we return 0

The run for this PR on libcrux is there:

• https://github.com/cryspen/libcrux/actions/runs/12068668021/job/33654275770

[franziskuskiefer]

@W95Psp please reference the issue that this is closing

[karthikbhargavan]

#771

[W95Psp]

https://github.com/cryspen/libcrux/actions/runs/12770740809/job/35596287076

[karthikbhargavan]

I hit this issue again yesterday when working on Bertie. Things were reordered with every change I made to some modules, for no good reason. I believe it also makes it hard to diff and debug the effect of engine changes (since the order change would make the diffs look much bigger than they are). So I encourage converting this into a reviewable PR whenever some other work item needs it.

[maximebuyse]

I tried fixing this PR today. The first problem with it is the following:

fn f() {h()}

fn g() {}

fn h(){f()}

Open this code snippet in the playground
In this case f and h don't get grouped together because all elements have a comparison result of 0. But we need f and h to be together because they are mutually recursive. I fixed that by grouping them afterwards (that's not too complicated). But there is a second more complicated problem:

fn no_dependency_1() {}

fn f() {g()}

fn no_dependency_2() {}

fn g() {}

Open this code snippet in the playground
This doesn't work well because the implementation of List.stable_sort in ocaml needs the relation to be transitive and here no_dependency_2 = f and no_dependency_2 = g but f != g which so List.stable_sort lets things in the same order instead of moving f after g.

This means we can either implement our own sort that solves this issue (something like https://blog.gapotchenko.com/stable-topological-sort). Or use the solution of #1140 (using ocamlgraph stable topological sort with the original ordering passed as a comparison function). Note that the specs of this are a bit different from what we want (it doesn't guarantee to keep cycles together), but the implementation corresponds to what we want (but we should make sure that this doesn't change).