trees that we want to skip

Some trees should be understandable by our interpreter, but it shouldn't do
anything about them. These trees are:
  1) EmptyTree (when used in an interpretable position it means "skip me")
  2) Type ascriptions and type applications (types are irrelevant to interpretation)
  3) Type definitions (for the same reason as #2)
  4) Imports (after typechecking, imports no longer matter, because typer has already resolved them)
interprets literals

Nothing fancy here, we just introduce a special method to go
from the world of JVM values to the world of interpreter values.

Note that we throw an unsupported exception when encountering classOf[T].
In principle, we could support those later on, but it's not that important
for macro interpretation, so let's skip that for now.
interprets blocks: immutability rocks!!

This commit shows off the niceties of immutable design.

Thanks to Env being immutable, interpretation of blocks is as simple as
interpretation of every statement from that block individually. Indeed,
purely functional programs compose very well!

Here we also introduce functions that update Env. We need three of those:
  1) Introduction of new local declaration into scope
  2) Assignment of a value's field
  3) Bulk import of global effects encapsulated by an instance of Env
interprets local declarations

The previous commit demonstrated updating the heap, and this commit
shows how to update lexical scope when we interpret local declarations.

Note that this code is only about locals. Since we ignore templates
(parts of classes, traits and modules) that define members, interpretation
never reaches non-local declarations.
interprets references

Sketches interpretation of references (Ident, Select and This nodes).

Note that typechecking normalizes all references, which means that all
qualified references become qualified, even if they were written unqualified.
For example `x` in the following code would become `this.x` in TST:

  class C {
    def x = 42
    println(x) // will be typechecked as println(this.x)
  }
interprets new

This commit handles another fundamental tree, and in this case there's
some sort of a twist.

The thing is that at a glance New seems to be completely unrelated to
its usages in Scala code (`new C`, `new C { ... }`, etc).

Handling of object instantiation is indeed quite an obscure area of scalac.

First of all, complex `new C { ... }` constructs (those that have multiple
parent classes or an explicitly specifed {...} block) are desugared into
an anonymous class definition + its instantiation.

Secondly, simple `new C(1, 2)` constructs are parsed in an unusual way:
Apply(Select(New(Ident(C)), <init>), List(1, 2). Quite a roundabout approach
to representing instantiation, right? Well, yes.

However, for our purposes this extravagant encoding of constructor invocations
actually makes a lot of sense. We can interpret New(_) in a very simple manner,
namely as creation of a raw Value, and then the constructor will be called
for us later when execution flows into the Apply part of the instantiation expression.