Award Emoji

This it first iteration of award emoji feature.
We have plan to extend emoji picker by the next release.

For now, you can add award by clicking to the emoji picker or posting a regular comment with emoji like ":+1:" and any other. You can post not only emoji that listed in the emoji picker.

See merge request !1825

When using IssuableFinder/IssuesFinder to find issues for multiple
projects it's more efficient to use a JOIN + a "WHERE project_id IN"
condition opposed to running a sub-query.

This change means that when finding issues without labels we're now
using the following SQL:

    SELECT issues.*
    FROM issues
    JOIN projects ON projects.id = issues.project_id

    LEFT JOIN label_links ON label_links.target_type = 'Issue'
                          AND label_links.target_id  = issues.id

    WHERE (
        projects.id IN (...)
        OR projects.visibility_level IN (20, 10)
    )
    AND issues.state IN ('opened','reopened')
    AND label_links.id IS NULL
    ORDER BY issues.id DESC;

instead of:

    SELECT issues.*
    FROM issues
    LEFT JOIN label_links ON label_links.target_type = 'Issue'
                          AND label_links.target_id  = issues.id

    WHERE issues.project_id IN (
        SELECT id
        FROM projects
        WHERE id IN (...)
        OR visibility_level IN (20,10)
    )
    AND issues.state IN ('opened','reopened')
    AND label_links.id IS NULL
    ORDER BY issues.id DESC;

The big benefit here is that in the last case PostgreSQL can't properly
use all available indexes. In particular it ends up performing a
sequence scan on the "label_links" table (processing around 290 000
rows). The new query is roughly 2x as fast as the old query.

By moving the default sort order into a separate scope (and calling this
from the default scope) we can more easily re-apply a default order
without having to specify the exact column/ordering all over the place.

These scopes can just sort by the "id" column in descending order to
achieve the same result. An added benefit is being able to perform a
backwards index scan (depending on the rest of the final query) instead
of having to actually sort data.

Sorting by both "created_at" and "id" in descending order is not needed
as simply sorting by "id" in descending order will already sort rows
from new to old. Depending on the query and data involved sorting twice
can also introduce significant overhead.

Show merge requests which close current issue

Closes #2903

### What does this MR do
If an issue is to be closed by a merge request the current user has access to, this will be displayed when the user looks at the issue.

![Screenshot_from_2015-10-12_12-10-37](https://gitlab.com/zj/gitlab-ce/uploads/52e429704e73067b24b69801f13ad7bc/Screenshot_from_2015-10-12_12-10-37.png)

/cc @DouweM

See merge request !1569

This ensures we don't end up running N+1 queries for the objects in the
affected collections.