This makes the typeclass mechanism able to use instances like [Is_true X -> Blah], where X reduces to X.

This happened for example in <[i:=x]>∅, where simpl unfold insert (despite
it being declared simpl never) because ∅ reduces to a constructor.

The previous commit is not really necesarry anymore, but my proof
for UIP of types with decidable equality is a bit more general, so
I won't revert it.

This way we get rid of the (unused) axiom eq_rect_eq reported by coqchk.

There is still the reals stuff, which is caused by importint Psatz (needed
for lia) and eq_rect_eq which is caused by importint Eqdep_dec.

Unfortunately, it still fails in iris.prelude.pretty.pretty_N_inj

With Coq 8.6, you can no longer have intro patterns that give more names than
the constructor has.  Also, patterns with too few names are now interpreted as
filling up with "?", rather than putting the unnamed parts into the goal again.

Furthermore, it seems the behavior of "simplify_eq/=" changed, I guess
hypotheses are considered in different order now.  I managed to work around
this, but it all seem kind of fragile.

The next compilation failure is an "Anyomaly: ... Please report", so that's what I will do.

Also cleanup the file a bit.

This change makes it possible to use hlists in the proof mode, which
itself uses hlists in the implementation of the specialize tactic.

This reverts commit 20b4ae55bdf00edb751ccdab3eb876cb9b13c99f, which does
not seem to work with Coq 8.5pl2 (I accidentally tested with 8.5pl1).

This makes type checking more directed, and somewhat more predictable.

On the downside, it makes it impossible to declare the singleton on
lists as an instance of SingletonM and the insert and alter operations
on functions as instances of Alter and Insert. However, these were not
used often anyway.

There was not really a need for the lattice type classes, so I removed
these.

These just make things more complicated, it would be more useful to
declare (efficient) decision procedures for each instance, so that
we can properly predict which instance we will get.

Similar files (gmap, listset, ...) were already in singular form and
matched the name of the set/map data type.

This class whose name is horrible and purpose is arbitrary seems to be a
leftover of some experiment with ch2o, a long time a ago.