Resolve the emoji.json "unicodes" mess

[mislav]

We now operate on a new set of assumptions:

• Characters with VARIATION_SELECTOR_15 shouldn't render as emoji, even if OS X doesn't respect that currently. This removes explicit aliases that include VARIATION_SELECTOR_15.
• VARIATION_SELECTOR_16 is optional for most characters to render as emoji on OS X. For those that don't have it optional, we include VARIATION_SELECTOR_16 in their raw representation in emoji.json. Other characters list their form including VARIATION_SELECTOR_16 implicitly in unicode_aliases.
• For emoji that consist of 2 characters + variation selector, we assume that the selector can come between the 2 characters or after them, so find_by_unicode now supports both forms.
• The db/aliases.html script ensures that emoji.json only contains characters that Safari on OS X actually renders as emojis.

This eliminates the need to have unicodes key in emoji.json, which simplifies things a bit.

Reverts parts of #56 but continues in the same philosophy: only render emojis that OS X renders by default.

/cc @aroben

[aroben]

Nice!

[mislav]

@aroben: Important question: just because OS X renders some emoji even when not suffixed with VARIATION_SELECTOR_16, I'm wondering whether we should.

Although a character like ♈ may render as emoji on Arial, it won't render as such on monospaced font (as you pointed out to me) without VARIATION_SELECTOR_16. So because this is font-dependent, I'm wondering whether we should be doing the replacement, since if we do it will always be replaced with a PNG no matter what the font.

[mislav]

But then again, even IE on Windows 8.1 renders non-suffixed characters as color emoji. (Not all of them, but most of them.)

So that would be a +1 for doing the replacement.

[aroben]

Yeah, the fact that it's all font-dependent makes it pretty tricky. We could just never replace native emoji with images inside monospaced text.

[mislav]

We could just never replace native emoji with images inside monospaced text.

We'll take care of it in client code then, at least when it comes to <pre> and <code>.

Alright I think I'm going to 🔫 first and ask questions later with this PR.

[aroben]

👍

[josh]

We'll take care of it in client code then, at least when it comes to <pre> and <code>.

You mean in js or the ruby rewriter? It seems like anything in a <pre> or <code> should never get <g-emoji> wrapped. html-pipeline could handle that concern, it has the parsed tree.

[mislav]

Right now we do insert <g-emoji> in <pre>:

🔥

But we could stop doing it. Anyway, further discussion about this will continue in a more appropriate place.

[josh]

But we could stop doing it. Anyway, further discussion about this will continue in a more appropriate place.

👍