This also solves a name clash with the extension order of CMRAs.

This is more consistent with CAS, which also can be used on any value.
Note that being able to (atomically) test for equality of any value and
being able to CAS on any value is not realistic. See the discussion at
https://gitlab.mpi-sws.org/FP/iris-coq/issues/26, and in particular JH
Jourdan's observation:

  I think indeed for heap_lang this is just too complicated.

  Anyway, the role of heap_lang is not to model any actual
  programming language, but rather to show that we can do proofs
  about certain programs. The fact that you can write unrealistic
  programs is not a problem, IMHO. The only thing which is important
  is that the program that we write are realistic (i.e., faithfully
  represents the algorithm we want to p

This commit is based on a commit by Zhen Zhang who generalized equality
to work on any literal (and not just integers).

This generalization is surprisingly easy in Iris 3.0, so I could not
resist not doing it :).

* Values are considered as atomic expressions (this does not hurt, and
  this makes the proofs of atomicity simpler).

I also reverted 7952bca4 since there is no need for atomic to be a
boolean predicate anymore. Moreover, I introduced a hint database
fsaV for solving side-conditions related to FSAs, in particular,
side-conditions related to expressions being atomic.

We reify to a representation of expressions that includes an explicit
constructor for closed terms. Substitution can then be implemented as
the identify, which enables us to perform it using computation.

This gets rid of the (ambiguous) notation %l, because we can declare
LitLoc as a coercion. It also shortens the code.

and show that this is an instance of evaluation contexts

This required a new ectx axiom: Positivity of evaluation contexts. This axiom was
also present in the old Iris 1.1 development, back when it still derived lifting
axioms for ectx languages.

Thanks to Amin Timany for the suggestion.

For consistency's sake.

get rid of substitution in Case (use lambdas); introduce Match as derived form that involves binders

We no longer abuse empty strings for anonymous binders. Instead, we
now have a data type for binders: a binder is either named or
anonymous.