Transformation intro_projections_counterexmp applies projection
functions transitively.

Transformation intro_projections_counterexmp support more
projections for a single type Ty.ty. The projections can have a name
and this name is appended to the name of the function symbol or
predicate being projected.

This is useful for records - for record type, there can be a projection
for each element of the type and the name of the projection can be
the name of the element.

triggering VC.

- Transformation intro_vc_vars_counterexamp introduces new constant with
model labels for every variable in the term that trigger VC and axiom
that this constant is equal to the variable, finds the position of the
term that trigger VC, and saves this position in meta (for smtv2
printer).

- Transformation prepare_for_counterexmp additionally performs the
transformation intro_vc_vars_counterexamp

- smtv2 printer no longer collects the location of the term that
triggers VC and does not collect variables in this term in a special
way. Note that this functionality was not yet completely removed from
the printer. It will be done so after the transformation
intro_vc_vars_counterexmp will be tested.

The rationale:
Variables that should be displayed in counterexample are marked
by model labels ("model", "model_projected", "model_trace:*").

Variables inside the term that triggers VC should be displayed in
counterexample for that VC. However, many VCs (tasks) can be generated
for  a signle *.mlw file and only variables in the term that trigger
the VC (task) that is currently proven should be displayed. That means
that the process of selecting variables inside the term that triggers
VC for counterexample must be done while processing the task. It is
done by transformation intro_vc_vars_counterexmp. This means that smtv2
printer no longer has to find the position of the term that triggers
VC and no longer has to collect variables in this term in a special
way.

Transformation intro_projections_counterexmp introduce new constant c
and axiom for all abstract functions and predicates p labeled with
label "model_projected", not only for these for that there exists
projection function. If the projection function does not exist,
the axiom states c = p, if there exists projection function f,
the axiom states c = f p.

counterexample was got.

the counter-example is empty while printing part of the counter-example
related to the term that triggers VC.

triggering VC was not collected.

premises.

VC only in the goal.

construct that triggers VC in Smtv2.info instead of global variable.

source-code location.

that triggers VC.

when a abstract construct has no user postcondition
we try to add one by purifying the program expression,
that is, ensures { result = t }, where t is a term
obtained from the program expression e

program expression e may involve function calls with
preconditions (e.g. array access, division)

the purpose of this change is to limit the number
of VCs by surrounding some program expressions with
abstract (e.g. if abstract i >= 0 && a[i] = 0 end then ...)

this is not a conservative change: one may have to
add ensures { true } to recover the previous behavior
(yet there is no example in the gallery of abstract e
with e pure and no post)

note: we might want to do that automatically for if-then-else
expressions (including lazy operators)

triggers VC in Model_parser.model and printing them.

in counter-example.