Remove rubyforge_project

This is deprecated by rubygems:
```
NOTE: Gem::Specification#rubyforge_project= is deprecated with no replacement. It will be removed on or after 2019-12-01.

Gem::Specification#rubyforge_project= called from /home/travis/build/sul-dlss/pre-assembly/vendor/bundle/ruby/2.5.0/specifications/mimemagic-0.3.3.gemspec:16.
```

Frozen string literal

Handle Office Open XML types for filed generated outside MSOffice

CI: rbx-3 in allow_failures, comment on Bundler

Travis: Use Bundler < 2

README: Use GitHub Markdown code fences

README: Use SVG badges

Add metadata uris

Add rubygems uris leading directly to changelog and other places. This
helps with automated gems management.

It turns out that the position of '[Content_Types].xml' is not fixed in
this format, and whereas MS Office adds it in the beginning in general,
when files are generated using Google Docs, or RubyXL, this is not
necessarily true. They might add it at the end, so all these would be
detected as application/zip.

This fixes #39

Change testing framework from bacon to minitest.

Gratipay is no longer a thing

Fixing API link and adding button to rubygems

Set available rbx name on Travis CI.

"rbx" does not exist in Travis.

Update .travis.yml.

* Add Ruby 2.4 and 2.5.
* Update old Ruby versions to use the latet version.

Docs: Introduce changelog

[ci skip]

Support IO-like objects efficiently

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.

Improve performance

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.