when calling soc.

Do not work all the times (eg, with arrays it generates C code that
does not compile). cf next changes.

Report by willie (cf mail of 8/10/2014 to get the file)

file:/tmp/modes3x2.lus

lus2lic -esa -en -2c /tmp/modes3x2.lus -n modes3x2

But it gives an error of:
Error. in file "/mnt/A/wsept/modes3x2_pre_orig_lus2lic_en_esa/modes3x2.lus",
line 74, col 8 to 8, token '#': only one operator per equation is allowed
(v04_0, v04_1).

Which is the line:
assert #(on_off, toggle);

-----------------------------------------------------------------

Actually, refuse programs that uses "#" or "nor" run with -esa and
-2c|-exec

That means that willie program is now rejected.

Nevertheless, that change migth fix some other programs (that uses
arrays, and used with -esa and -exec or -2c).

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.

Basically, I've missed some substitutions in Merge and in clocks.

This one was spotted by willie.

Add an option --to-c-dont-inline-predef to get the previous behavior.

I've just switched to ocaml 4.02, and it works only on carlit because
of GLIC 2.14 is not installed on other machine.

also, add some missing files.

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.

e.g., by replacing "plus" by "iplus" or "rplus"

Hence now the following is accepted :
   res = map<<+,  N>>(x, a, b);

but still not

  a_or_b = map<<Lustre::if,  N>>(x, a, b);

For instance,
  node toto = map<<Lustre::if,  N>>(x, a, b);
is rejected.

The problem with this change is that we now also reject equations such as
   res = map<<+,  N>>(x, a, b);

which could be avoided. Probably L2lRmPoly does its job partially.

cf git sha 55d3d77c470f416befd16a1b7d47f751eb2171fc of rdbg

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.

Fix a bug in socExec.ml (strangely untriggered before) along the way.