As noted in the code, setuptools 11.3 deprecated EntryPoint.load and
its require parameter. Starting with 11.3 the preferred way is use
EntryPoint.require and EntryPoint.resolve as necessary. Unfortunately,
those methods do not exist in all versions of setuptools. So we have
to check for them and use them when they're available. Otherwise, we
fallback to using EntryPoint.load with the require parameter.

Closes #59
Closes #90

Refactor how we use StyleGuides for better error recovery

In bug 74 we discovered that there are some less than ideal problems
around our use of multiprocessing. This is a first attempt at fixing
74 by using a fake StyleGuide object which proxies to the real one,
and will catch and handle exceptions and then posibly retry the
operation we were trying to perform in the first place.

Currently we're only implementing that logic for StyleGuide.check_files
but we should be careful to implement this in other functions used in
hooks and elsewhere.

Note: there may be a simpler way to fix this with a context manager
that will do the right thing. That may also prove simpler to implement
but that will have a much larger impact on the code-base than this.

Related to bug #74

See merge request !36

This updates our retry logic to be more specific in catching OSErrors
and it adds specific tests to show that it works and properly
re-initializes the StyleGuide with the pep8.StandardReport class so we
can fall back on serial behaviour gracefully.

Closes #74

This allows us to reuse the same code simply for check_files and
input_file. This should cover all uses of the StyleGuide methods.

Related to bug #74

In bug 74 we discovered that there are some less than ideal problems
around our use of multiprocessing. This is a first attempt at fixing
74 by using a fake StyleGuide object which proxies to the real one,
and will catch and handle exceptions and then posibly retry the
operation we were trying to perform in the first place.

Currently we're only implementing that logic for StyleGuide.check_files
but we should be careful to implement this in other functions used in
hooks and elsewhere.

Note: there may be a simpler way to fix this with a context manager
that will do the right thing. That may also prove simpler to implement
but that will have a much larger impact on the code-base than this.

Related to bug #74

Handle EPIPE IOErrors when using more than 1 job

If someone is using flake8 and piping it to a command like `head`, the
command they are piping flake8's output too may close the pipe earlier
than flake8 expects. To avoid extraneous exception output being printed,
we now catch IOErrors and check their errnos to ensure they're something
we know we can ignore.

This also provides flexibility to add further errnos for ignoring on a
case-by-case basis.

Closes #69

See merge request !35

This should prevent bug 69 from regressing in the future and provides a
framework for testing the addition of new errnos to the ingore list.

If someone is using flake8 and piping it to a command like `head`, the
command they are piping flake8's output too may close the pipe earlier
than flake8 expects. To avoid extraneous exception output being printed,
we now catch IOErrors and check their errnos to ensure they're something
we know we can ignore.

This also provides flexibility to add further errnos for ignoring on a
case-by-case basis.

Closes #69

docs: Adding flake8-import-order plugin to the list of available plugins

Solves #77

See merge request !34