This pull request adds logic to handle interactions between Literal and
Final: for example, inferring that `foo` has type `Literal[3]` when
doing `foo: Final = 3`.

A few additional notes:

1. This unfortunately had the side-effect of causing some of the
   existing tests for `Final` become noiser. I decided to mostly
   bias towards preserving the original error messages by modifying
   many of the existing variable assignments to explicitly use
   things like `Final[int]`.

   I left in the new error messages in a few cases -- mostly in cases
   where I was able to add them in a relatively tidy way.

   Let me know if this needs to be handled differently.

2. Since mypy uses 'Final', this means that once this PR lands, mypy
   itself will actually be using Literal types (albeit somewhat
   indirectly) for the first time.

   I'm not fully sure what the ramifications of this are. For example,
   do we need to detour and add support for literal types to mypyc?

3. Are there any major users of `Final` other then mypy? It didn't seem
   like we were really using it in our internal codebase at least, but
   I could be wrong about that.

   If there *are* some people who have already started depending on
   'Final', maybe we should defer landing this PR until Literal types
   are more stable to avoid disrupting them. I had to make a few changes
   to mypy's own source code to get it to type check under these new
   semantics, for example.

This commit modifies this PR to make selecting the type of final
variables context-sensitive. Now, when we do:

    x: Final = 1

...the variable `x` is normally inferred to be of type `int`. However,
if that variable is used in a context which expects `Literal`, we infer
the literal type.

This commit also removes some of the hacks to mypy and the tests that
the first iteration added.

# Conflicts:
#	test-data/unit/check-literal.test

# Conflicts:
#	test-data/unit/check-literal.test

…2a/mypy into add-literal-final-interactions