Remove a lot of warnings (considered as errors by dune).

Indeed, having two different mechanisms is bad.

In the end, I've kept mine (and not the one of Pascal), because the
it was depending on LicPrg.t, which was creating a circular dep
(which could of course be fixed, but I am lazy).

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.

It was beacause the tables in LicVarName were cleaned and because the way
this module work sucks...

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

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

cf test/should_work/NONREG/fresh_name.lus

where the local variable _n1e1_1 was defined twice !

The fix contist the following idea : prefix fresh var name by "_",
   except if at least one user ident begins by "_". In that case, we
   try to prefix them by "_1", and then "_2", and so on. We take the
   first possible one.

   nb : this won't work if the user defined idents from "_1" to
   "_1073741823" (on 32-bits machine), but I bet that this compiler
   would die before anyway...

In  short, the  rationale for  this change,  is that  it is  having a
recursive node_exp is
- useless,
- too complicated,
- wrong w.r.t. nesting iterator calls

In long:

- It is useless because, at the  Eff level, a node cannot call itself
  via one  of its  static arg (which  was where the  recursivity came
  from).

- and indeed, it  is much simpler to consider that  a static arg node
  can only be ident.long that identifies a node alias.

  This  means of  course, that  nested iterators  have  been unnested
  before,   inventing  alias   node  names   along  the   way...  And
  polymorphism makes thing difficult once again.

- But the  *big* problem  with a recursive  node_exp is that  it make
  things very  complicated to (lic)dump nested  iterator call because
  of polymorphism!   Actually, it  even makes thing  complicated when
  the iterators were themselves not nested in the source code !

  Some ugly  things were done in  LicDump to unnest  those calls when
  printing node_exp.   But this uglyness  have a price:  tricky code,
  and bugs! Indeed, nested iterators calls were wong for example when
  using  the --inline-iterator  mode (but  i would  not  be surprised
  that is wrong in other cases...).

Hence,  LicDump  is  simpler,  but  of course  LazyCompiler  is  more
complicated.  But  this  is  reasonable:  a  pretty-printer  is  not
supposed to be complicated.

To  do  that, we  centralized  the ident  name  creation  into a  new
dedicated module Name.

+ fix should_work/NONREG/param_node.lus, we contained a combinational loop.