(i was on the wrong branch)

- add sub_tree_size, parent, is_in_tree, is_out_tree
- fix height (was only working for out-trees)
- a predessors to Topology.t
- refactor a lot of strange things in the code
  - in the use of hashtbl in particular

and attach  the pid to  the list of neighbors  of returned by  the get
function. Indeed, this is needed in some anomymous (or semi-anonymous)
algorithms, such as the k-clustering.

The previous  scheme was to  define everything  that is common  to all
user nodes in  a file named state.ml. This file was supposed to define
the algo  state type,  as well  as optional  functions such  as fault,
legitimate, or potential.

But in  order to be  able to define,  say, a legitimate  function that
uses user  nodes (which is the  case for dijkstra token  ring) without
introducing any dependency loop, it  is necessary to split state.ml in
two modules.

The new module is called Config (config.ml).

nb: I had to modify the GenSessions module in rdbg to reflect this change !

Update: add the potential value of the current state as an output of sasa programs in the rdbg plugin
if the potentioal function is provided

It now takes  as first argument the whole list  of processes (not only
the enabled ones).

In  Algo.pf_info, the  action  field  is now  an  option  type (if  is
correspond to a process that has not been activated).

nb: does not really work yet.

Update: add the previous state in argument of the fault function.

New: add a fault functions to the Algo (to inject fault when a legitimate configuratiuon is reached).

nb: I needed to  split Main to avoid a Module self-loop  (as I need to
use do_step in Daemon).

The  rationale is  that the  Algo.spid that  gave processes  access to
their pid via their neighbors was a bit weird. Also, it makes the anonymity
of the algorithm more explicit: an access to the pid could appear anywhere
in the program, while now, the pid must be in state.t!

Now, if the  user needs the pid,  he must store it  explicitly in the
state via the initialization function.

To force that, I've changed the Register interface (and thus GenRegister)

The rationale is that:
- in lurette mode, they should be the same for all algos already
- in batch mode, action declarations are ignored anyway (except in custom mode)

as it is where they belong.

Indeed, during the explanations, it makes more sense to start with the state.

Doc: rework the documentation of the Algo API.

Add use it to add an oracle to the BFS