iOS and Android asset generation options (for discussion)

Hey!

I've implemented a first take on iOS asset generation options. I'm an iOS/Android developer and plan to continue working on this and to active use it in everyday work. This pull request is meant to open the discussion about the way Adobe wants these features implemented, not for actual merging.

There's a bunch of stuff added here:

1. Ability to add arbitrary type-checked options at the end of a component spec, like `myfile.png iOS padTo=100x100`. The options and their types are declared at the start of the file, see TYPES and OPTIONS.

2. `pad` option that accepts a CSS-like list of dimensions and adds the specified top/right/bottom/left paddings, e.g. `pad=0:0:3:0`. The units are ignored for now, always assumed to be pixels.

3. `padTo` option that pads the image to the specified size, e.g. `padTo=64x64`.

4. `padToMultipleOf` option that pads the image so that it's a multiple of the specified size (this option can only be enabled via `iOS` option right now)

4. `iOS` option that actually turns the current component into two components, for 1x and 2x assets. So `image.png ios` is turned into an equivalent of `50% image.png, image@2x.png padToMultipleOf=2`, and `pad` and `padTo` values are also correctly scaled for the 1x asset.

I'm open to re-imagining and re-implementing these options in a way that can eventually be merged into the mainline. Until then, I'll be maintaining my fork. I realize it can be a long time, judging from other enhancement requests, and that the final syntax will probably look nothing like the current one.

I intend to add a similar option for Android resources in about a month (or maybe sooner) as well, and maybe other features based on my actual usage experience.

Known problems:

* test coverage is minimal (just a few parsing tests)
* pad, padTo ignore the units, always assume pixels — should either disallow units, or support any units
* the current design is assumed to be for Retina displays (2x, aka 320 dpi); this is adequate for iOS use cases, but some Android designs may be done at 3x now or in the future; we could use current document's ppi to determine this, although that probably will be an obstacle for most users; I'm yet to see a design PSD that isn't using the default 72 ppi value