Introduce `MemoryKind` abstraction

Introduce `MemoryKind` abstraction

Re-cast the notion of "heap" (in liveness, SSA, and value-numbering) as
one of potentially many `MemoryKind`s, called `GcHeap`.  Update names,
comments, data structures, and signatures as appropriate to parameterize
relevant data/methods over `MemoryKind`.  This change is a no-diff
refactoring, and currently `GcHeap` is the only `MemoryKind`.  Generally,
codepaths which will generically need to process all `MemoryKinds`s
(initializing, dumping, dataflow propagation) now iterate over all
`MemoryKinds`, and codepaths which are sensitive to the semantics of the
specific `MemoryKind` (def/use identification in liveness and value
numbering) are changed to specifically operate on `MemoryKind::GcHeap`.

One notable exception is that `lvMemoryPerSsaData` and `CountForMemoryDef`
are *not* parameterized over `MemoryKind`; there's a single "space" of SSA
defnums for memory defs (though the same tree can incur different defs for
different memory kinds [in which case their defnums will differ]), to
facilitate subsequently sharing SSA nodes across memory kinds when
appropriate.

Commit migrated from https://github.com/dotnet/coreclr/commit/463502f9e70e39cd460091298b338a065b8631f2