Create "@2x" high-res icon assets for Mac builds

[IonoclastBrigham]

This is just a bit of visual polish for Mac users with high-density screens. I think we can just copy or link to the corresponding next-size-up asset in the implicit "@1x" icon set for all but the largest one. We'd just need to add the final image which we can generate at build time from the .SVG original.

Concerns and possible risks:

• I'm not 100% sure making a copy of e.g. the 512px asset and renaming it icon_256x256@2x.png will work, or if the system will respect the embedded screen density setting. Need to look this up in the docs
• Generating the last, biggest @2x item at build time, and possibly making double-density versions of the ones we already have should be a fairly simple terminal command in the makefile, though it may add another 3rd party dependency.
• For example, using ImageMagick we can do something like convert -size 512x512 img/ivy-logo.svg mac.iconset/icon_256x256@2x.png, possibly adding arguments to set the embedded density tag; OS X doesn't ship with ImageMagick though, so users would need to get it from MacPorts, Homebrew, source tarball, etc.
• Testing shows that while the icon itself has a specific height, exporting it this way @ 1024x1024 stretched the canvas, resulting in a double-size image with the icon up in the top-left quarter. This might be fixed with a scaling parameter to ImageMagick, or it might require tweaking the SVG definition.

[lehitoskin]

Also, according to the docs, we can tell raco to set the incs rather than having us moving them inside the .app ourselves: raco exe --icns ‹.icns-path›

[audreytoskin]

@IonoclastBrigham
Does OS X actually require using the @2x file naming scheme? I'm mostly familiar with with the use of @2x file names when applying the principles of "responsive design" to images in a web page. And in that case, I think the new HTML5 standards (the srcset attribute or the picture element) offered a better, more flexible solution. I don't like how @2x treats the lower resolution as the standard base -- even smart phones are starting to get high-density screens -- and I kind of think using @2x in the filename just looks weird.

I do like the idea of using ImageMagick (or possibly GraphicsMagick) to take care of exporting the SVG at different sizes. Adding a build requirement will be less of an issue when we add binary packages, right?

[IonoclastBrigham]

1.0 was just released as binary packages for windows, linux, and os x. So yeah, the build dependency is irrelevant for the average user. And anyone who can install racket and build ivy from source likely already has ImageMagick installed. This is probably okay.

To your point, Mac and iOS apps can bundle copies of their raster assets with @2x and @3x variants for higher-density screens. This is equivalent to the drawable-Xdpi directory structure, for Android apps. It's not strictly necessary, as the system will try to pick the best version available, and scale it if needed. But it could potentially look kinda janky, so if you want control over how it looks, you provide them.

Alternatively, we might be able to use a vector version directly, though it might need to be exported from svg to some intermediate format. I know a lot of iOS/OS X graphics get packaged up as PDFs, but I'm not sure you can do that kinda thing with app icons.

[lehitoskin]

Update: read-bitmap has the optional keyword argument #:try-@2x?