this is of course unsafe, yet useful if you have proved absence of
overflows independently or if you are happy with a partial correctness
proof (that is, if there is no overflow then the postcondition holds)

this is work in progress; nothing plugged in yet

Conflicts:
	src/ide/gmain.ml

Conflicts:
	drivers/cvc4_bare.drv
	share/provers-detection-data.conf
	src/driver/driver_parser.mly
	src/printer/smtv2.ml

p labeled with label "model_projected" for that it exists a projection
function f creates declaration of new constant c and axiom stating that
c = f p

Projection functions are functions tagged with meta "model_projection".
Function f is projection function for abstract function and predicate p
if f is tagged with meta "model_projection" and has a single argument
of the same type as is the type of p.

This transformation is needed in situations when we want to display not
value of a variable, but value of a projection function applied to a variable.

Note that since Why3 supports namespaces (different projection functions
can have the same name) and input languages of solvers typically not,
Why3 renames projection functions to avoid name clashes.
This is why it is not possible to just store the name of the projection
function in a label and than query the solver directly for the value of
the projection.
Also, it means that this transformation should thus be executed before
this renaming.

1. Strong region updates can only work with direct assignments, e.g.
     r.contents <- something_completely_different
   but not with functions such as (:=) : ref 'a -> 'a -> unit
   Why3 requires 'a to be instantiated with one concrete type,
   not with a bunch of types that differ in their regions.

2. Strong region updates will restrict the updated regions to their
   covers. However, in the current implementation, Why3 does not know
   if the region corresponding to the field "contents" is the only
   cover for 'a in the type [ref 'a] or if there is a way to retrieve
   'a from [ref 'a] without going through "contents". Therefore, to
   ensure soundness, a strong update of r.contents will forbid to
   use r itself. A solution consists in writing an adhoc "reference"
   type, where the mutable contents (O.t in this case) is explicitly
   given in the type definition. Then the strong update of the field
   containing O.t will preserve the covering "reference".

   This problem is fixed in the "new system", where mutable types
   carry information about the access paths of the type variables.
   There, "r.contents <- something_different" preserves r.

http://linuxtesting.org/astraver)