(does not make much sense without polymorphism)

Coq realization for int.Power (mostly to keep Coq proofs that were in power.mlw)

prover shortcuts: the shortcuts information can be in the prover section in order to reduce the number of section in why3.conf

side-effect: function syntax in driver now accepts %v0, %v1, etc.
for type variable instantiations (order is given by variable name)

simplified example mjrty.mlw using that module

   shortcuts are defined in why3.conf. They are automatically
   generated using two mechanism:
   - a shortcut section in prover-detection-data.conf creates a shortcut
   for the first prover that match the regexp

   - the identifier used as family argument for the prover section in
   prover-detection-data.conf is used as shortcut for the prover. If
   different sections use the same argument the first one that match an
   existing prover is used for the shortcut.

       Remove the id in prover that is used only for command-line, use
       instead the name,version,alternative of the prover. One can
       also use regular expression (start with ^).

       "Alt-Ergo,0.92,with arrays" corresponds only to one prover
       "Alt-Ergo,^0\.9.*,with arrays" correspond to all the Alt-Ergo prover with arrays which version match "0\.9.*"
       "Alt-Ergo" is the same thing than "Alt-Ergo,^,^"
       "Alt-Ergo,0.92," corresponds only to one prover with the alternate fields empty
       "Alt-Ergo,,with arrays" corresponds to "Alt-Ergo,^,with arrays" since the version is never empty.

       Provers identification are case sensitive even if it is
       currently more complicated for the user because
       case-insensitiveness is not sufficient. Specifiying "alt-ergo"
       for "Alt-Ergo,^,^" is great, but not if there is more than one
       match. A more general system of shortcut would be more
       appropriate.

Don't use anymore the family argument.

1) For every block, for every executable call the prover using the
version switch and add the prover to the configuration if the version
match one of the version_ok or version_old but none of the version_bad
2) We consider that an executable name which appears in a block, but
which version isn't a version_ok, version_old or version_bad has an
unknown version
3) For every executable which have an unknown version, we add the
prover using the first block that contains it.

So the order of the block is used only when the version of an
executable appears in none of the block.

A block with more than one exec fields is now the same thing than if
you split the block into blocks containing one field.

New message field that allows to print a message when a prover is
detected. If a message is not present, we print ", Ok." if the version
is good (version_good) and not old, and " (it is an old version)." if
the version is old (version_old).

The field command can be missing in a block, in that case the block
defines a version known to be buggy: no prover config is generated.

Transformation induction sur l'ordre lexicographique suivant la définition des types : les labels d'utilisateur pris en compte