Ditto for Misc and Compile

Indeed, in order to sort Soc.gao, I currently process in 3 stages ;
1. compute a total ordering of Actions.t according to the deps
2. transform Actions.t into Soc.gao (List.map)
3. factorize Soc.gao by looking at consecutive gao that have the same guard

With this change, between steps 1 and 2, I reorder the list of actions
so that group of independent actions are sorted according to their
clock. The idea is of course to provide to step 3 more opportunities
of factorization.

The result is not very convincing yet.

I've also tried to sort the actions wrt their clock before performing
the toposort. Seems not too bad.

I've kept the old behavior by default though.

Indeed it is possible when each branch of the ite updates no memory.
This is done in the new L2lOptimIte module.

For the time being, it does detect when the node has no memory. It
only looks at the declaration: nodes have memory, and not functions.

I should infer that information and raise warnings or errors if what
I infer is not compatible with waht is declared (will come later).

Also split ActionsDep into ActionsDep and Action.

Also fix a bug in L2lsplit where deeply nested (>2) merge were not
splitted.

Also fix a bug in Lic2soc.make_e2a_elt where some deps and some
actions were lost. Actually, this bug ought to be triggered only with
nested calls. So this affects only programs executed via the
-knc/-keep-nested-calls option. and -2c is not supposed to work in
conjunction with -knc ! Hence this fix does not fix anything. But
still it fixes potentially future code if I (or someone else) decide
to handle nested calls in the lic one day.

Indeed, computing the dependencies and choosing an order for actions
(that may optimize test openning in the near futurea) are 2 different
things.

nb : the -exec mode was working because I did not use the generated soc,
which was completely wrong.

Note that to do that, I have modified the CURRENT variant of
Lic.val_exp, to attach it the clock the current holds on. Indeed, the
clock is mandatory to generated correct code...

In an ideal world, this clock information may have explicitely been
set by the user ("current(clk_of_X,X)" instead of "current(X)"), but
for historical reason, it is not the case.

Hence, this information is added as soon as it is available, namely,
during clock checking.

Add the modes3x2 exemple of Pascal (its version + a la V6 version).

Fix the doc wrt the merge exemple (the tex was refering to a
non-existant file).

More specifically, replace @ by rev_append and flatten+map by fold_left.

On a file that has 11000 equations (normal.ec), I win a factor 4: 60s -> 15s

The main difference is that I use a map instead of list to store
visited nodes.  The compilation time of normal.ec is divided by 2!!
(35s->15s)

We do not really see the difference in the time of the non-reg tests
since the execution of normal.ec still exceeds the 10s timeouts.

 nb : #FAILS=84->81

Add --gen-autotest option that generates  a Lutin file and an oracle Lustre file suitable to compare the result of 2 Lustre compilers

As far as ldbg is concerned, it only traces the toplevel node, at
call event.

Note that I needed to rename quite a lot of modules to avoid name clashes
between lus2lic.a and ltop.

I've also merged the Verbose module with the one of Lutin so that
they can be shared (there were sharing 95% already).

I took the data type definition from SocExecValue to define a Data
module that is a strict extension of the Lutin Data module.

The duplicated Genlex module is now also identical to the one of
Lurette.

Quite boring, but simple thanks to the ocaml type system.

nb : programs do run, but I did not check that they run correctly...

Also fix a regression introduced in the previous change where
incorrect ec code was generated for diese.

Indeed, the data structure in output of the lis2loc parser was very
similar to Lic.t/LicPrg.t. Hence, this shunt.

At this stage it compiles, but it's untested and does not work.