It can be infered now.

This reverts commit 849abb8d, reversing changes
made to 8de0b894.  The merge was done
accidentally, before review happened.

This is derived from `wp_forget_not_stuck` and a trivial preorder on
stuckness bits. (The two lemmas are redundant, but I have examples
where each seems more natural than the other.)

I did *not* bake `wp_stuckness_mono` into `strong_mono` for two
reasons. Mainly, I didn't see a nice way to combine the two proofs
(beyond `cut`). Less important, changing the type of `wp_strong_mono`
will break code.

I saw no need for `stuckness_flip`: strong atomicity always works,
while weak atomicity works only for expressions that are not stuck.
Since this seemed unclear, I split lemma `wp_atomic'` up into
`wp_strong_atomic` (parametric in the WP's `s`) and `wp_weak_atomic`
(not). The proof mode instance is stated in terms of the derived rule
`wp_atomic` (parametric in `s`).

Pull progress bit out of the WP fixpoint,
make (most) wp adequacy notation only parsing, and
generalize forget_progress.

This class, in combination with `TCForall`, turns out the useful in
LambdaRust to express that lists of expressions are values.

(□ P) now means (bi_bare (bi_persistently P)).

This is motivated by the fact that these two modalities are rarely
used separately.

In the case of an affine BI, we keep the □ notation. This means that a
bi_bare is inserted each time we use □. Hence, a few adaptations need
to be done in the proof mode class instances.

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

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