so that we don't have to fetch it for non-forks

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13416#note_37193731

So we just try a cheaper way to detect it if it works or not

This helps keep the abstraction layers simpler, and also keep the
interface of those methods consistent, in case of implementation
changes.

Closes gitaly#443

Group milestones can only be referred to by name, not IID. They also do not
support cross-project references.

The method User#projects_limit_left would run "personal_projects.count"
but such a query is not memoized. As a result multiple calls to
User#projects_limit_left would result in multiple COUNT(*) queries being
executed.

To work around this this commit adds User#personal_projects_count which
simply memoizes the result of the COUNT(*) in an instance variable.

The "events" table has a foreign key on "events.project_id" with a
cascading delete. As such it's impossible for an event to have a
non-existing project ID.

Closes gitaly#433

it's not there in the case of personal snippets, f. ex., and we've
already guarded against its being missing in #find_notification_setting

Previously, we stored these as serialised fields - `st_{commits,diffs}` - on the
`merge_request_diffs` table. These now have their own tables -
`merge_request_diff_{commits,diffs}` - with a column for each attribute of the
serialised data.

Add a background migration to go through the existing MR diffs and migrate them
to the new format. Ignore any contents that cannot be displayed. Assuming that
we have 5 million rows to migrate, and each batch of 2,500 rows can be
completed in 5 minutes, this will take about 7 days to migrate everything.

First round of review, main changes:
- templates.title is human readable, #name will be passed around
- GitLabProjectImporterService has been renamed