- the move_count node was wrong (missing parenthesis)
- the lemma an the theorem only holds for locally central unfait demon

The generation scheme is now makes it easier to write oracles that do
not depend on the topology.  The idea is to generate an oracle
(specific to the graph) that includes a file that the user should
provide, and which ougth to define a generic oracle, i.e., depending
on m and n (process and actions numbers).

nb: this demon is not fair: it is biased by the degree of nodes.

Add use it to add an oracle to the BFS

Took into account Erwan's comments and changed Register module such that the properties are computed on first call (except height that is computed on each call because it depends on the chosen tree's root)

Add use it to add an oracle to the BFS

Basically, the idea is to parse the result of the registred ('s ->
string) function.

For instance if  the user define 'v and 'v printer as follows:

 type state = { a : int ; b : float }
 let state_to_string s = Printf.sprintf "x=%d y=%f" s.v1 s.v2

pid_x and pid_y will be used as output var names in the RIF outputs.

If the user provide no name:
 let state_to_string s = Printf.sprintf "%d %f" s.v1 s.v2

some names will be invented (pid_v0 and pid_v1)

All the get_* functions (that are of no interest for users) are now in
the Register module.

Things that are currently broken:
- the ability to init vars in the dot
- controling the name of local vars in the rif output

The idea is to use the Obj module (arg !!!), which is safe thanks to
the fact that there is now only one register function, which forces all the
'v to be bound to the same type.

But I bumped into the "value restriction" limitation
https://stackoverflow.com/questions/22507448/the-value-restriction

Indeed, I need to store functions of 'v in some tables (or references),

And tables are necessaryly weakly polymorphic !

https://v1.realworldocaml.org/v1/en/html/imperative-programming-1.html#side-effects-and-weak-polymorphism

Indeed, by using the Env.nset and Env.nget defined in
0d6575a7 a pb that was hided by the
use of Env.set and Env.get was triggered.

The bug was that variables initialisations were done several times.

In sasa.ml, the way I was updating the Env.t by iterating on the
variables was forcing to "close" expressions that were calling init
functions.

The rationale is that
 - it is not always the cmxs that is necessary .e.g., rdbg uses .cma or .ml
 - it makes more sense to refer to the source code

This can be used from rdbg from example, to generate session files.

In particular, 'rdbg -lurette' now works thanls to this option
(cf rdbg sha 63566a893807361691137cafe15854a2a7395eec)

Remove the --generate-rdbg-load one that is less general

Save/restore the PRGS at checkpoints (necessary for internal demons).

This is necessary because I cannot Dynlink .cmxs files from a ocaml
toplevel. Hence, one way to load the algos from rdbg is to
#load .cma files. This option generates an ocaml file that
can be #used by automatically generated rdbg-session.ml files.

Rationale: it was not really necessary (Algo.neighbor contains almost
the same information), and the Topology.neighbor type was alone in its
module, which looked weird.