Add a per-run cache for member symbols

We are all used to calls to `definitions.PredefModule`, or
`defintions.Predef_???` to grab the symbol of some well known
entity. But you'll notice that some of these are lazy vals,
and others are defs.

Why is this so? In the presentation compiler, a member like
`Predef.???` will be assigned a new symbol after the user
browses into `Predef.scala`.

Mistakenly using vals in definitions leads to subtle
IDE bugs like SI-7678. We are able to trigger these
situations in tests, as noted in the comments of that issue.

Changing the vals to defs, on the other hand, has a performance
penalty. Some schemes to workaround this have shown up:
cache them per-implicit search, or compare method names and owners
rather than symbols on hot paths in the type checker.

This commit introduces a facility to cache these sort of symbols
per-run, and uses it to check for `Predef.conforms` and
and for the class/type tag materializers.

A followup pull request (WIP: https://github.com/retronym/scala/compare/ticket/7678-2)
will expand the use of to address the widespread and unsafe caching
of member symbols that I found while investigating SI-7678.
SI-7678 Don't cache member symbols of TypeTags in Definitions.

It we can only safely use vals in Definitions for top-level symbols.
Otherwise, when the IDE switches to loading the symbol from source,
we can hold on to a stale symbol, which in turn impedes implicit
materialization of TypeTags.

This commit moves (most) of the accessors for member symbols
into RunDefinitions, and changes calling code accordingly.
This is a win for presentation compiler correctness, and
might even shave of a few cycles.

In a few cases, I have had to leave a `def` to a member symbol
in Definitions so we can get to it from the SymbolTable cake,
which doesn't see RunDefinitions.

The macro FastTrack facility now correctly recreates the mapping
from Symbol to macro implementation each run, using a new facility
in perRunCaches to create a run-indexed cache.

The enclosed test recreates the situation reported in the ticket,
in which TypeTags.scala is loaded from source.