fix: installing a tarball after a registered plugin works properly @W-21915680@

[jfeingold35]

Fixes @W-21915680@ and closes #1294 .

OKAY, this is a really weird one.
When you install a plugin via its hosted name (e.g., sf plugins install code-analyzer) and then install some other plugin via a local tarball (e.g., sf plugins install "file:///Users/blahblah/salesforce-plugin-update-v2.1.3.tgz"), if the second plugin's name is alphabetically after the first plugin's name, then the install of the second plugin subtly fails.

The install will seem to succeed, but if you look carefully you'll see installing plugin file:///.....-vX.Y.Z.tgz... installed vA.B.C, where XYZ is the version of the tarball and ABC is the version of the first plugin. And if you look at ~/.local/share/sf/package.json, then you'll see that the tarball location simply overrode the declared location of the first plugin. This doesn't appear to interfere with the first plugin's behavior in any noticeable way, but it does mean that the second plugin won't work at all.

The cause was that the matching operation to compare the tarball's package information to the known dependencies wasn't taking typing into account, so it was just auto-matching to the alphabetically first dependency it checked. This is why the bug is only reproducible when you have multiple dependencies and the second plugin is alphabetically after the first.

I believe that my fix is safe, as it adds test coverage for the scenario in question, and those tests fail without my changes and succeed with them. But I'm not sure, as this code is somewhat mysterious.

[git2gus]

Git2Gus App is installed but the .git2gus/config.json doesn't have right values. You should add the required configuration.