EpsFilePlugin Speed improvements.

[wiredfool]

Fix for #838.

@karstenw -- Sorry on the delay for this. This should be what we've discussed in #838, stripped down to remove excess code in a few places.

• Universal line ending wrappers are called for files
• There's a shim for doing line endings for BytesIO/StringIO.
• The initial read is done on the bare fp, so no line ending translation is done.
• If it's a file, ghostscript should use the file without copying, if not, it writes to a temp file first.

[coveralls]

Changes Unknown when pulling 918c77e on wiredfool:epsfile-rebase into * on python-pillow:master*.

[wiredfool]

2 notes. I've disabled some tests that weren't testing our code. They do pass where expected, and fail in a portion that's an edge case in the spec.

Those tests indicate that the way that we're treating the line endings isn't 100% to spec if we use the builtin python universal line endings file wrappers. We can do it correctly, but slower, by only using our internal python file pointer wrapper PSFile. This should only be an issue if an eps file mixes line endings in one file or uses the really messed up \n\r combination.

[coveralls]

Changes Unknown when pulling ce0fcef on wiredfool:epsfile-rebase into * on python-pillow:master*.

[karstenw]

Since we're reading only comments and an empty line simply does not count as a comment, as would be the case with \n\r, I'm still in favor of using universal+'ignore empty lines'.

Let's not forget that GS does the work even though source comments indicate otherwise.

All we need to do is read as much meta data as we can get from the ps/eps.