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).

Also Merge the Global and the MainArg module as they were
(bizzarely) both handling command args options.

In order to do that, I've generalised the type of merge : now the clock
argument can be any expression. Some assert false still prevent its use,
but it should be easy to get rid of them (I'll do that latter).

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.

1) At the Lic level, there's no reason to distinguish betwenn node
calls, and predef node calls. Indeed it makes things simpler and more
homogeneous afterwards.

2) int strings are only converted when necessary (constant evaluation).

3) const are handled directly under Lic.by_pos_op instead of being under
   PREDEF_CALL, which make things easier and more logical.

BTW, put everything that concerns node environement into the new
IdSolver module (from the Lic module).

Indeed, part of licDump was done in lic, but that part should
not depend in the compil option.

Pascal prepared « the field » for that change.

 - translate merge on bools in terms of current and ite
 - do not print the clock info in node profile in en mode

+ various fixes in lustre test files.

nb : now all tests in the should_work dir passes !!!

Also, force the merge to operate over an ident rather than on any val_exp.

nb : do not work for lv4/ec mode

Also fix some bugs in DumpLic when printing condact in other modes.

Plug back the enums expansion (-ee, --expand-enums) that translates enum types using extern consts and types.

nb : I've transformed all the regressions I've seen into todo entries
in todo.org.

nb 2 : I did not mv the newly broken tests into the broken dirs. I'll
do that for those I do not want to fix in the short term.

nb: les tests ne passent toujours bien sur.

* Partie lus -> AST

predef.ml -> srcPredef.ml
syntaxTreeCore.ml -> astCore.ml
syntaxTree.ml     -> astV6.ml
syntaxTreeDump.mli-> astV6Dump.mli

* Partie Ast -> Ast

solveIdent.mli -> astRecognizePredef.mli
syntaxTab.mli -> astTab.mli
symbolTab.mli -> astTabSymbol.mli

* Partie  AST -> lic (static evaluation)

eff.ml  -> lic.ml
getEff.mli -> ast2lic.mli
lazyCompiler.mli -> licTab.mli
builtIn.ml -> licMetaOp.ml
predefEval*.ml -> licEval*.ml
name.mli -> licName.mli

* Partie Lic -> Lic

uniqueOutput.mli      -> l2lCheckOutputs.mli
structArrayExpand.mli -> l2lExpandArrays.mli
nodesExpand.mli       -> l2lExpandNodes.mli
doNoPoly.ml           -> l2lRmPoly.ml
doAliasTypes.ml       -> l2lAliasType.ml
doSplit.ml            -> l2lSplit.ml

- plus de macros prefefinies (e.g. FILL, BOOLRED etc...)
  (remplacé par la notion de BuiltIn)
- split.ml adapté et remanié pour rentrer dans le moule
  source to source (voir DoSplit)

et donc ne marchent plus !

IDENT remplacé par VAR_REF/CONST_REF
- plus de node_exp dans les CALL, juste une ref (node_key)
- reste a faire pareil pour les NodeStaticArgEff

importante du mecanisme de UnifyType :
- fait :
  * definition de Eff.poly_match
  * TypeVar type_var au lieu de Any/Overload
    avec type_var = Any | AnyNum
    (pour l'instant et pour longtemps ?!)
- à faire :
  * revoir UnifyType pour qu'il rende un poly_match
  * stocker là où c'est nécessaire les poly_match
    calculés lors du type check
    (pour les CALL et peut-être les sargs ?)

parametric nodes (or predef iterators) are nested.

Before, nested iterators were handles as follows : a source-level
(i.e., not compiled) alias node was created on-the-fly, and then
compiled. But this way to proceed was buggy for static args coming
from nested iterators or nested parametric nodes.

Now, I rely on Inline.iterators to get rid of iterators (the iterator
inlining is now recursive).

not use the module name. Otherwise, names with "::" are created, and
sometimes the lhs of the "::" does not even correpond to an existing
module.