Previously if we passed in an IO object which doesn't respond to #seek,
MimeMagic would read the whole IO into memory. And this is exactly the
type of objects that the Shrine file upload library deals with.

However, we can also "seek" by blank-reading that many bytes, and always
rewinding to the beginning, which is what we've implemented in this
change.

This change also doesn't require IOs to respond to #binmode.

If you speed up detection of common MIME types, you speed up MIME type
detection in general.

Previously we had to separate branches which did the same thing, one was
for IOs and other was for strings. However, if we wrap the string into a
StringIO, we can use the same branch for both.

Sometimes the first instance of the word/ or ppt/ is not in the first 2000 bytes - 5000 should cover it.

The freedesktop magic doesn't work for the Office 2007+ files, it
detects them all as application/zip. I have magic which detects them,
but it requires looking at 2,000 byte ranges, too much for their
project (which has to support things like file browsers). Since you
already warn that `by_magic` is slow, it'd be nice to support it here
at least.

This would allow the paperclip project to use mimemagic and stop
relying on the `file` binary:

  - https://github.com/thoughtbot/paperclip/issues/1530#issuecomment-43375497

Support is enabled through an overlay, required with

    require 'mimemagic/overlay'

Documentation is in the README

Updated by_magic() to work with Ruby 2.0 - tries to call .b on string so they are compared as binary

It's possible for vague magic to cause the wrong filetype to be
detected.  For instance, application/x-gmc-link is seriously
vague (tons of files have "URL:" in the first 32 bytes!).  This
allows you to remove the conflicting filetypes that you're sure
you'll never see.