`bundle_report` may confuse a git-sourced gem with a remote public gem

[JuanVqz]

Description

Follow-up to #29.

bundle_report outdated looks up each installed gem's latest version on rubygems by name only (Gem.latest_spec_for(name)). A gem pulled in from a git source (e.g. gem "foo", github: "org/foo") that happens to share its name with an unrelated public gem on rubygems is matched against the public one and reported as out-of-date with a bogus upgrade suggestion.

This is the same root cause as #29, which fixed it for locally-sourced (path:) gems via GemInfo#sourced_locally?. Git-sourced gems still have the problem: in BundleReport.outdated they are only counted (sourced_from_git), not excluded from the out-of-date check.

Expected behavior

bundle_report outdated should exclude git-sourced gems from the out-of-date comparison, just like it now does for locally-sourced gems, so they are not matched against a same-named public gem on rubygems. They are already reported separately via the "N gems are sourced from git" line.

Steps to reproduce

1. In a test project, declare a gem from git whose name matches an existing public rubygems gem, e.g. gem "app_store", github: "<some-fork>/app_store".
2. Make sure the public gem on rubygems has a higher version number than the git checkout.
3. Run bundle install, then bundle_report outdated.
4. Observe the git-sourced gem listed as out-of-date with an upgrade to the unrelated public version.

Notes

• The fix should mirror bundle_report may confuse local private gem with remote public gem #29: exclude sourced_from_git gems from out_of_date_gems in NextRails::BundleReport.outdated (lib/next_rails/bundle_report.rb). GemInfo#sourced_from_git? already exists.

I will abide by the code of conduct

[JuanVqz]

I'll wait until #29 is merged