We already supported framing under wands.

For example, framing `P` in `(P ∨ Q) ∗ R` now succeeds and turns the goal into `R`.

This should fix iris-examples.

This used to be done by using `ElimModal` in backwards direction. Having
a separate type class for this gets rid of some hacks:

- Both `Hint Mode`s in forward and backwards direction for `ElimModal`.
- Weird type class precedence hacks to make sure the right instance is picked.
  These were needed because using `ElimModal` in backwards direction caused
  ambiguity.

This was an oversight in !63.

Replace/remove some occurences of `persistently` into `persistent` where the property instead of the modality is used.

Rename `UCMRA` → `Ucmra`
Rename `CMRA` → `Cmra`
Rename `OFE` → `Ofe` (`Ofe` was already used partially, but many occurences were missing)
Rename `STS` → `Sts`
Rename `DRA` → `Dra`

I have reimplemented the tactic for introduction of ∀s/pures using type
classes, which directly made it much more modular.

The advantage is that we can directly use a Coq introduction pattern
`cpat` to perform actions to the pure assertion. Before, this had
to be done in several steps:

  iDestruct ... as "[Htmp ...]"; iDestruct "Htmp" as %cpat.

That is, one had to introduce a temporary name.

I expect this to be quite useful in various developments as many of
e.g. our invariants are written as:

  ∃ x1 .. x2, ⌜ pure stuff ⌝ ∗ spacial stuff.

This causes a bit of backwards incompatibility: it may now succeed with
later stripping below unlocked/TC transparent definitions. This problem
actually occured for `wsat`.

persistent context.

Given the source does not contain a box:

- Before: no-op if there is a Persistent instance.
- Now: no-op in all cases.

when using iCombine.

This enables things like `iSpecialize ("H2" with "H1") in the below:

  "H1" : P
  ---------□
  "H2" : □ P -∗ Q
  ---------∗
  R

For example, when having `H : ▷ P → Q` and `HP : P`, we can now
do `iSpecialize ("H" with "HP")`. This is achieved by putting a
`FromAssumption` premise in the base instance for `IntoWand`.

This commit fixes the issues that refolding of big operators did not work nicely
in the proof mode, e.g., given:

    Goal forall M (P : nat → uPred M) l,
      ([∗ list] x ∈ 10 :: l, P x) -∗ True.
    Proof. iIntros (M P l) "[H1 H2]".

We got:

    "H1" : P 10
    "H2" : (fix
            big_opL (M0 : ofeT) (o : M0 → M0 → M0) (H : Monoid o) (A : Type)
                    (f : nat → A → M0) (xs : list A) {struct xs} : M0 :=
              match xs with
              | [] => monoid_unit
              | x :: xs0 => o (f 0 x) (big_opL M0 o H A (λ n : nat, f (S n)) xs0)
              end) (uPredC M) uPred_sep uPred.uPred_sep_monoid nat
             (λ _ x : nat, P x) l
    --------------------------------------∗
    True

The problem here is that proof mode looked for an instance of `IntoAnd` for
`[∗ list] x ∈ 10 :: l, P x` and then applies the instance for separating conjunction
without folding back the fixpoint. This problem is not specific to the Iris proof
mode, but more of a general problem of Coq's `apply`, for example:

    Goal forall x l, Forall (fun _ => True) (map S (x :: l)).
    Proof.
      intros x l. constructor.

Gives:

     Forall (λ _ : nat, True)
       ((fix map (l0 : list nat) : list nat :=
          match l0 with
          | [] => []
          | a :: t => S a :: map t
          end) l)

This commit fixes this issue by making the big operators type class opaque and instead
handle them solely via corresponding type classes instances for the proof mode tactics.

Furthermore, note that we already had instances for persistence and timelessness. Those
were really needed; computation did not help to establish persistence when the list in
question was not a ground term. In fact, the sitation was worse, to establish persistence
of `[∗ list] x ∈ 10 :: l, P x` it could either use the persistence instance of big ops
directly, or use the persistency instance for `∗` first. Worst case, this can lead to an
exponential blow up because of back tracking.

Big ops over list with a cons reduce, hence these just follow
immediately from conversion.