Issue #247, fix how custom fetchers are handled

[zlav]

Expected format of locator URL is:
/api/cli/custom+6214/git@github.com:zlav/pastport.git$SHAVALUE/latest_build
Output with NormalizeGitURL:
/api/cli/custom+6214/github.com/zlav/pastport$SHAVALUE/latest_build

[elldritch]

This problem looks like the other way around: we are correctly normalising on test but are not correctly normalising on upload. The github.com/user/project form is canonical.

The reasoning here is that GitHub repositories are sometimes cloned via the HTTPS link and sometimes via the SSH link, and these links should point to the same FOSSA project. This mix-up is common enough that we handle GitHub as a special case (and we should probably also handle BitBucket and GitLab).

If we "fix" this correctly (by normalising on upload), we'll break existing projects in a minor way. New uploads to the projects that use the HTTPS locator will instead use the canonical locator. This might cause project-ignored issues to reappear.

A couple approaches to this issue:

1. Fix this correctly, and migrate HTTPS custom locator projects in the backend to canonical locators. Users running old versions of the CLI will still experience confusion (their CLI will still upload to the HTTPS locator).
2. Fix this correctly, and increment the configuration file version. On older configuration file versions, preserve the existing upload behaviour. That said, ephemeral .fossa.yml configurations are a common pattern in CI, which means configuration file version may not be a reliable indicator of the CLI version that the project was first uploaded with.
3. Do not normalise at all (which is what this PR does), which can cause inadvertent mix-ups.
4. Fix this correctly, then add logic for backwards compatibility with older projects. Specifically, uploading and testing should use the exact locator when that project already exists and the canonical locator otherwise.
5. Fix this correctly, and don't do any data migration.

(1), (2), (4), and (5) are likely to cause confusion. I'm leaning towards either (2) or (3).

[elldritch]

As we discussed offline, this is good to merge. The expectation is a follow-up PR that refactors Locator.String and ensures there are no locator modifications elsewhere.