The proof mode now explicitly keeps track of anonymous hypotheses (i.e.
hypotheses that are introduced by the introduction pattern `?`). Consider:

  Lemma foo {M} (P Q R : uPred M) : P -∗ (Q ∗ R) -∗ Q ∗ P.
  Proof. iIntros "? [H ?]". iFrame "H". iFrame. Qed.

After the `iIntros`, the goal will be:

  _ : P
  "H" : Q
  _ : R
  --------------------------------------∗
  Q ∗ P

Anonymous hypotheses are displayed in a special way (`_ : P`). An important
property of the new anonymous hypotheses is that it is no longer possible to
refer to them by name, whereas before, anonymous hypotheses were given some
arbitrary fresh name (typically prefixed by `~`).

Note tactics can still operate on these anonymous hypotheses. For example, both
`iFrame` and `iAssumption`, as well as the symbolic execution tactics, will
use them. The only thing that is not possible is to refer to them yourself,
for example, in an introduction, specialization or selection pattern.

Advantages of the new approach:

- Proofs become more robust as one cannot accidentally refer to anonymous
  hypotheses by their fresh name.
- Fresh name generation becomes considerably easier. Since anonymous hypotheses
  are internally represented by natural numbers (of type `N`), we can just fold
  over the hypotheses and take the max plus one. This thus solve issue #101.

This solves issue #100: the proof mode notation is sometimes not printed. As
Ralf discovered, the problem is that there are two overlapping notations:

```coq
Notation "P ⊢ Q" := (uPred_entails P Q).
```

And the "proof mode" notation:

```
Notation "Γ '--------------------------------------' □ Δ '--------------------------------------' ∗ Q" :=
  (of_envs (Envs Γ Δ) ⊢ Q%I).
```

These two notations overlap, so, when having a "proof mode" goal of the shape
`of_envs (Envs Γ Δ) ⊢ Q%I`, how do we know which notation is Coq going to pick
for pretty printing this goal? As we have seen, this choice depends on the
import order (since both notations appear in different files), and as such, Coq
sometimes (unintendedly) uses the first notation instead of the latter.

The idea of this commit is to wrap `of_envs (Envs Γ Δ) ⊢ Q%I` into a definition
so that there is no ambiguity for the pretty printer anymore.

This commit is based on code by Amin Timany.

This way, it can be used with `iApply`.

This is to be used on top of stdpp's 4b5d254e.

Now that we have the plain modality, we can get rid of the basic updates
in the soundness statement.

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`.

We used to normalize the goal, and then checked whether it was of
a certain shape. Since `uPred_valid P` normalized to `True ⊢ P`,
there was no way of making a distinction between the two, hence
`True ⊢ P` was treated as `uPred_valid P`.

In this commit, I use type classes to check whether the goal is of
a certain shape. Since we declared `uPred_valid` as `Typeclasses
Opaque`, we can now make a distinction between `True ⊢ P` and
`uPred_valid P`.

For obsolete reasons, that no longer seem to apply, we used ∅ as the
unit.

This makes it easier to frame or introduce some modalities before introducing
universal quantifiers.

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

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

Instead, I have introduced a type class `Monoid` that is used by the big operators:

    Class Monoid {M : ofeT} (o : M → M → M) := {
      monoid_unit : M;
      monoid_ne : NonExpansive2 o;
      monoid_assoc : Assoc (≡) o;
      monoid_comm : Comm (≡) o;
      monoid_left_id : LeftId (≡) monoid_unit o;
      monoid_right_id : RightId (≡) monoid_unit o;
    }.

Note that the operation is an argument because we want to have multiple monoids over
the same type (for example, on `uPred`s we have monoids for `∗`, `∧`, and `∨`). However,
we do bundle the unit because:

- If we would not, the unit would appear explicitly in an implicit argument of the
  big operators, which confuses rewrite. By bundling the unit in the `Monoid` class
  it is hidden, and hence rewrite won't even see it.
- The unit is unique.

We could in principle have big ops over setoids instead of OFEs. However, since we do
not have a canonical structure for bundled setoids, I did not go that way.

This way, iSplit will work when one side is persistent.