This patch also fully qualifies some realized types and constructors to
avoid inadvertent shadowing.

* declare range types and float types,
* use integer (resp. real) literals for those types through casting,
* specify how to print them in drivers.

Change in syntax
* use

  type t = < range 1 2 >   (* integers from 1 to 2 *)
  type t' = < float 4 12 > (* float with 4 bits in exponent and 12 in mantissa *)

  the two projections :
  t'int
  t''real

  and the predicate :
  t''isFinite

* Restrict the use of "'" in whyml:
  Users are not allowed to introduce names where a quote symbol
  is followed by a letter. Thus, the following identifiers are
  valid:

  t'
  toto'0''
  toto'_phi

  whereas toto'phi is not.

Note: we do not yet support negative numbers in range declaration
and casting of a literal.

except for modules/impset.mlw (because of Fset) and modules/mach/*
(because of program cloning), the standard library now typechecks.

This is still very much the work in progress. Many functions and
predicates have still to be converted to "let function" and
"let predicate". Here are some TODOs:
- do not require the return type for "val predicate", "val lemma", etc.
- do not require explicit variant for "let rec" if the code passes
  the termination check in Decl (see list.why)
- what should become "val ghost function" and what should stay just
  "function" (see array.mlw, matrix.mlw, string.mlw, etc)?
- some defined functions in algebra.why and relations.why had to be
  removed, so that they can be implemented with "let function" in
  int.mlw (since they are defined, they cannot be instantiated with
  let-functions). This seems too restrictive. One way out would be
  to authorise instantiation of defined functions (with a VC).
- should we keep the keyword "model"? reuse of "abstract" in types
  breaks syntax coloring ("abstract" requires closing "end" in
  programs but not in types; maybe we can drop that "end" again?).

Currently, the builtin theory why3.HighOrd (or just HighOrd) must
be explicitly "use"-d. However, the type (HighOrd.func 'a 'b) can
be written ('a -> 'b), and the type (HighOrd.pred 'a) can be written
('a -> bool), and the application operation (HighOrd.(@)) can be
written as the usual juxtaposition. Thus, normally, you do not have
to write the qualifiers. The builtin theory why3.Bool (or just Bool)
is needed for "bool". The names "HighOrd", "func", "pred", and "(@)"
are not yet fixed and may change.

"eliminate_epsilon" tries to be smart when a lambda (or some other
comprehension form) occurs under equality or at the top of a definition.
We could go even further and replace (\ x . t) s with t[x <- s], without
lifting the lambda. I'm not sure it's worth it: we rarely write redexes
manually. They can and will appear through inlining, though.

Anyone who wants to construct epsilon-terms directly using the API
should remember that these are not Hilbert's epsilons: by writing
an epsilon term, you postulate the existence (though not necessarily
uniqueness) of the described object, and "eliminate_epsilon" will
happily convert it to an axiom expressing this existence. We only
use epsilons to write comprehensions whose soundness is guaranteed
by a background theory, e.g. lambda-calculus.

 - use the syntax of the driver for the own realization of a theory
 - add a *_def lemma for defined logics with syntax
 - add comments that inform which syntax is used for declared logic

Remove the incorrect Coq realization of PowerReal.pow by Rpower, since the
latter is only meaningfully defined for positive first arguments, e.g.
Rpower (-1) 3 = 1!

Add monoids to the algebraic hierarchy.

Note that the file is still generated at compilation time.

The "realized" meta takes two arguments. The first one is the path+name of
the theory, the second one is the translation of it for the target prover.
The meta is supposed to be put into a printer file, so there is no
ambiguity on the target. The second argument can be left empty if it can be
inferred from the first one.

Note that the first argument is not really satisfactory, since it is
redundant with the theory part of the driver. Moreover, its handling is a
bit crude: it does not take into account rich qualifiers and it does not
generate proper error messages if it does not match the theory.

How to use it:

    why3 --realize -D drivers/coq-realize.drv -T real.Real -o .

        produces Real.v in the current directory

    why3 --realize -D drivers/coq-realize.drv -T real.Real

        produces real/Real.v in the loadpath near real.why
        (the directory "real" must exist)

If a realization file is already there, it is passed to
the printer in order to preserve the proofs.

Instead of -D <driver_file>, you can use -P <prover>,
if that prover uses a corresponding driver. However,
the prover itself is not used.

You can only realize theories from the loadpath.

At the moment, coq-realize.drv is the only driver
capable to realize theories in some sensible way.
For any other driver, the results may be funny.

Realization of WhyML modules is not possible so far.

Realization may break if you directories and filenames
contain non-alphanumeric symbols.

The whole thing is in very preliminary stage.
Use with caution.

This is getting tedious. There should be a way to drop the content of a
whole theory.

introduced new transformation eliminate_non_struct_recursion for that purpose
uses Decl.check_termination tomake the check and the pretty-print
(could probably be improved to avoid 3 calls to check_termination)