@kha @dselsam FYI
The original motivation for saving/restoring the cache was not
correctness, but cache size management. When we go inside a binder
using the telescope methods, we extend the local context with new fresh
free variables, execute the action `k` using the new extended local
context, and then restore it. Any cached result containing these
fresh variables is dead after executing `k`. So, `savingCache` here
could be viewed as a "checkpoint". However, it also removes any
cached entry that does not contain the new fresh variables.
I found this inconvenient in practice, and it is the wrong choice
in a few cases. Example: we have a `forall` expr (aka arrow), and use a
telescope to go inside, and then invoke TC. If the telescope uses
`savingCache`, we lose the cached TC instance witness. This is
wasteful since the witness often doesn't even depend on the new fresh
free variables created by the telescope.
Thus, this commit removes the `savingCache` occurrences from
the "telescope" methods. Users may still manually use it if
they think it is appropriate. That is, they can write
```lean
savingCache $ forallTelescope e $ fun xs body => <code>
```
if they really want to discard any new cache entry created while
executing `<code>`.
It is the first step to integrate the new type class procedure intro
`MetaM`. It implements the main entry point where we preprocess the
instance, check cache, invoke main function, process replacements, and
cache result.
While stage 1 is still the main build and the source of `bin/lean`, we now have optional targets
* lean_stage2, lean_stage3: build respective executable in `<build>/shell` from previous stage, compiling the stdlib
from scratch
* bin_lean_stage2: copy `lean_stage2` to `bin/` (stage 3 should always be identical to stage 2)
