Get emoji list & aliases from data file instead of symlinks

_Alternative to #44_

Previously, emoji name & unicode aliases were determined by following symlinks among `images/emoji/*.png`. This led to nontrivial code for resolving these aliases, made it tricky for contributors to add new aliases and inspect existing ones, and didn't leave room for adding metadata to emojis such as tags or descriptions from the Unicode spec.

Moreover, the aliases as symlinks led to duplication of image assets in users' applications, with `hocho.png` and `knife.png` representing the same emoji but being two separate images. Users were also unsure what to do with `unicode/{HEX-NAME}.png` files, which would end up among their images after running the `:emoji` task.

This change removes the symlinks support and creates the list of emojis and their aliases in `emoji.txt`. A single emoji is now represented with an Emoji::Character instance, which has the `image_filename` method to determine the path to the corresponding image instead of having to construct it manually.

**This is kind of a breaking change, however.** Since neither `hocho.png` nor `knife.png` images won't exist anymore in people's image assets (only the `unicode/{HEX-CODE}.png` version of each emoji), simply gsubbing `:knife:` with `<img src="/images/emoji/knife.png">` won't work anymore. Instead, users need to look up the Emoji::Character and use its `image_filename` method. I believe this is a worthwhile breaking change, since it gives us leverage to shift things around internally in future revisions (such as changing the images naming scheme) and not have to break anything for users again.

/cc @josh @muan
Similarly, gemoji used to map U+26BD to this image. Both Windows and OS X do that. Is it intentional that we're no longer doing so? (There are more examples of this kind of thing, I just wanted to point out a couple.)