This reverts commit 2a7755fe because
it is no longer needed after Matthieu Sozeau reverted this change in
Coq 8.6. See also the discussion:

  [Coq-Club] Coq 8.6 typeclasses behavior change

at 11/16/2016 02:14 PM.

We need instances like EqDecision and Countable for it. We could
redeclare those instead, though.

In Coq 8.6 type class search is not called recursively on premises
that are not type classes. To that end, we use a hint extern to invoke
an ordinary auto.

Many useful properties are probably still missing.

(These instances are not defined for any FinMap to avoid overlapping
instances for EqDecision, which may have awkward consequences for
type class search).

There is no way to infer the cmra A, so we make it explicit.

This way we avoid the env_cbv tactic unfolding string related stuff
that appears in the goal and hypotheses of the proof mode.

Having Is_true as a type class caused problems with rewrite: when the
rewrited lemma has a premise of the shape Is_true, the rewrite tactic
will complain that it cannot find a type class instance, instead
of generating a goal for that premise.

This reverts commit f3222ba2 because
it broke the machinery for determining whether a term is closed.

Example, by Morten:

  Definition dummy : val :=
    λ: <>, #true || #false.

Use symbol ∗ for separating conjunction.

The old choice for ★ was a arbitrary: the precedence of the ASCII asterisk * was fixed at a wrong level in Coq, so we had to pick another symbol. The ★ was a random choice from a unicode chart.

The new symbol ∗ (as proposed by David Swasey) corresponds better to conventional practise and matches the symbol we use on paper.

See merge request !21

The old choice for ★ was a arbitrary: the precedence of the ASCII asterisk *
was fixed at a wrong level in Coq, so we had to pick another symbol. The ★ was
a random choice from a unicode chart.

The new symbol ∗ (as proposed by David Swasey) corresponds better to
conventional practise and matches the symbol we use on paper.

Change the way we handle view shifts in post-conditions

Now we try to avoid adding them unnecessarily, so we don't have to remove them automatically any more.

The overall tally in the proofs (i.e., excluding changes in proof mode and lifting lemmas) is: 14 removed `iModIntro` (and equivalent tactics), 7 insertions of `wp_fupd`. So it seems we actually more often do not need that final update than we do need it. Not to mention this also simplifies the lifting lemmas and the proof mode, doing less unnecessary work (adding updates and then removing them again).

On the minus side, *if* the update is missing, unexperienced users will have a hard time figuring out what to do. The change typically needs to be made at the beginning of the proof, the problem only surfaces at the end. This could be mitigated by providing a tactic for proving texan triples that does the `wp_fupd` (and the introducing the `\Phi`). While this would re-add most of the 14 removed `iModIntro`, we could still keep the simplified lifting lemmas and proof mode.

Cc @robbertkrebbers @jjourdan what do you think?

See merge request !20

This should make theme asier to parse, "{{{ v, v; l |-> v }}}" looks rather funny.