create iris-deprecated and iris-staging packages, and deprecate some hard-to-use logic-level wrappers as well as view shift and Hoare triple notation

Done with a script by Tej; see
iris/iris!609 for details.

This reverts commit 71a1fbf0, reversing
changes made to ce12f3a6.

Gregory Malecha authored Mar 16, 2020 and Robbert Krebbers committed Mar 16, 2020

- remove "odd" comment
- move atomic triples to bi_scope

The general idea is to first import/export modules which are further
than the current one, and then import/export modules which are close
dependencies.

This commit tries to use the same order of imports for every file, and
describes the convention in ProofGuide.md. There is one exception,
where we do not follow said convention: in program_logic/weakestpre.v,
using that order would break printing of texan triples (??).

This MR is a follow up on the renamings performed (implicitly) as part of
!215. This MR makes the following changes:

- `auth_both_frac_valid` and `auth_both_valid` are now of the same shape
  as `auth_both_frac_validN` and `auth_both_validN`. That is, both are
  now biimplications.
- The left-to-right  direction of `auth_both_frac_valid` and
  `auth_both_valid` only holds in case the camera is discrete. The
  right-to-left versions for non-discrete cameras are prefixed `_2`, the
  convention that we use throughout the development.
- Change the direction of lemmas like `auth_frag_valid` and
  `auth_auth_valid` so that it's consistent with the other lemmas. I.e.
  make sure that the ◯ and ● are always on the LHS of the biimplication.

This is in preparation for coq/coq#9274.

New IntoAcc typeclass to decouple creating and elliminating accessors; ElimInv supports both with and without Hclose

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`

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

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.