Map projects per ID: Prepare migration scripts

[applejag]

Depends on #12

Projects are currently mapped to their corresponding provider via name. Name can change, such as when a project is moved, but ID does not.

This is such a fundamentally impactful change that we need to be cautious and perhaps make a bunch of migration scripts.

Suggested change would be that the project in Wharfs DB is mapped to the git server and the project ID within that server. For example "gitlab.local" and "193".

---

There has come up a case where the current implementation caused a bug. Especially since the current GitLab importer actually maps the auth token with the project display name.

See the code (redacted link, it was outdated anyway, but pointed to somewhere in: https://github.com/iver-wharf/wharf-provider-gitlab/blob/master/import.go)
It would make more sense if it used the "path" instead of "name" property of the repo. To show the difference of the two, here a screenshot of GitLabs docs with an example project called "Diaspora Client" but with the path "dispora-client"

A project that is damaged by this is Foo Bar, which is accessed via the path "foo-bar" but has the name "Foo Bar" https://gitlab.local/default/foo-bar
When it tries to build docker images it builds them with the destination
harbor.local/default/Foo Bar:latest, which is an invalid docker image name.

---

There so much auto-magic and assumed relations tied together here. We need to find a way to migrate the data in as a painless and future-proof way as possible.

Migrating to basing projects off the project ID and server domain instead is a good step in my (@jilleJr's) opinion.
Then we can also import meta data for it such as it's full path so that we later can use that value for default docker image names instead of these home-baked spagetti relations.

---

• prepare migration script, test it locally (16h, 123). Applying them on production (manual vs automatic) is a separate task

[Alexamakans]

As agreed upon during internal discussion, we will skip migration completely and have existing projects get their remote project ID when refreshed in the front-end, as this leads to far less complexity and dev time.