Add UTF-8 BOM to gemspec

Apparently there's a little-encountered issue with file encodings when you're using capistrano to deploy.  The short of it is that the use of UTF-8 characters in this project's gemspec causes the deployment to fail because of parsing errors.  The solution is simple, to add a UTF-8 Byte Order Mark to the gemspec file so the parser knows the encoding when it opens the file.  I've done that in this commit.

I believe the use of UTF-8 characters is due to the authors' names listed in the files.  Nothing against UTF-8, but if this fix is deemed the proper solution it would be good for those authors to take note so as to avoid future issues.  This one was a bit tricky to track down.

You can set the BOM on a file in vim with the command ":set bomb". [sic]

The full detail:

When adding spree_email_to_friend to my existing Spree 1.2 store, I had just to go back to a pre-1.3 commit and everything worked great in development.

I have a standard production box built on Ubuntu 12.04.1 using a vanilla Spree Deployment Service setup.  When I deployed, everything looked fine, but the "Email a friend" link failed to show up.

Soon I determined that the deployment had silently failed to come up and had simply left the old instance running.  When I examined /data/spree/current/log/bluepill.log (forgive me if that path isn't perfect, it's from memory), I found the following error:

179 I, [2013-01-08T14:37:36.954954 #32209]  INFO -- : executing ["/data/spree/shared/bundle/ruby/1.9.1/bin/unicorn_rails", "-c", "/data/spree/shared/config/unicorn.rb
180 /usr/local/lib/ruby/gems/1.9.1/gems/bundler-1.2.3/lib/bundler.rb:294:in `block in load_gemspec_uncached': invalid byte sequence in US-ASCII (ArgumentError)

Googling the error, I found this article:

https://github.com/railsmachine/moonshine/wiki/ArgumentError%3A-invalid-byte-sequence-in-US-ASCII

Which explained the source of the error and suggests forcing your project to use UTF-8 processing for all parsing.  I tested it and it worked.

However this is non-optimal and a workaround because it hardwires the formatting for all files, which are supposed to be able to declare their own encoding.  For example, that breaks UTF-16 files from being used in the project (presumably, I haven't tested this).

The correct fix is for the offending file to declare that it is UTF-8 by using the BOM.  I tested this in my deployment and it resolved the issue without having to resort to the workaround.