This is the smallest possible change to get mypy passing on the
jsonschema codebase. The goal of this configuration is to enforce type
annotations anywhere that they appear.
That is, if a method is added to the codebase,

    def foo(x: int) -> str:
        return str(x)

then usages of `foo` will by type checked. If no annotations are
added, `mypy` will not type check functions.

For the most part, this keeps the impact low. The one exceptional case
is the use of `pyrsistent.pmap` as an argument to
`attr.ib(converter=...)`. Unfortunately, it causes `mypy` to
incorrectly deduce the type of the init parameter created by attrs. We
need to "explain the type of init" to mypy by creating a callable with
a concrete type to act as the converter. The callable in question
simply wraps `pmap` with a cast and presents the desired type
information to mypy.

mypy can handle `if sys.version_info` checking better than
`try ... except ImportError`. This is somewhat disappointing, but the
rewrite of these import lines isn't that bad and aligns with the
recommendations of the mypy docs.

In pypy3, the following line is invalid:

    x: Tuple[dict, dict] = {}, {}

but this variant *is* valid:

    x: Tuple[dict, dict] = ({}, {})

Apply this correction where it occurs in test_validators.py

Use of the `__future__` import of annotations allows several niceties,
in particular:
- parametrization of builtin types as generics
- `|` syntax for unions (including `| None` for optionals)

Update to use the future import wherever it improves or simplifies
annotations.

Avoid using new typing features outside of annotations (e.g. in
assignment), which fails on older pythons. This is an unfortunate
wart in the way that the future import works.

Nitpick was failing on

    TYPE_CHECKER: ClassVar[TypeChecker]

It's not clear what to do about this. `TypeChecker` was imported
correctly from `jsonschema._types` and is noted in the doc as
`jsonschema.TypeChecker`. We can't import the `jsonschema` name at
runtime because that would be circular.

To resolve, use `typing.TYPE_CHECKING` to conditionally import
`jsonschema` at type-checking time. This avoids the circular
import but allows us to write

    TYPE_CHECKER: ClassVar[jsonschema.TypeChecker]

As a result, Sphinx correctly builds a cross-reference from the
annotation, the annotation is still accurate, and runtime behavior
is left untouched.

Type annotations can use variable names in order to support easily
named constructs (e.g. `FooType = Union[int, str]; x: FooType`).
However, such variable names are then seen by sphinx autodoc, which
does not evaluate them. As a result, for such a name to avoid tripping
nitpick warnings, these names need to be resolvable.

The simplest resolution is to remove the use of any internal variables
for this purpose (at least where they would be seen by sphinx), and
use the longhand description of types in such cases.

`_format.py` had a few internal variables to make type annotations
shorter to write. However, these can cause issues with sphinx
nitpick. Even though the variables removed in this commit aren't
causing a build failure, removing them is a good precaution.

These blocks only exist to create code which evaluates under mypy
but does not run at runtime. As a result, they are impossible to cover
with `coverage` on a testsuite, and make sense to exclude from
coverage reporting.