Introduce disable_local_revision_check config

[rafaelfranca]

This config, in combination with disable_local_branch_check make it
so local.library configuration work in the same way as changing
them Gemfile to point to a path.

This is useful specially in bisect scripts, which will change the HEAD
of the repository to point to a commit that will not include the commit
specified in the Gemfile.lock.

[welcome]

Thanks for opening a pull request and helping make RubyGems and Bundler better! Someone from the RubyGems team will take a look at your pull request shortly and leave any feedback. Please make sure that your pull request has tests for any changes or added functionality.

We use GitHub Actions to test and make sure your change works functionally and uses acceptable conventions, you can review the current progress of GitHub Actions in the PR status window below.

If you have any questions or concerns that you wish to ask, feel free to leave a comment in this PR or join our #rubygems or #bundler channel on Slack.

For more information about contributing to the RubyGems project feel free to review our CONTRIBUTING guide

[simi]

Looks good to me.

🤔 To simplify this a little, we can unify both settings to disable checks to one setting key -> disable_local_git_check. But that can be done later if needed.

[deivid-rodriguez]

Hi @rafaelfranca, thanks for this!

I'm not sure I understand the reason for this PR very well. I sometimes bisect using bundle config local. and things work just fine for me.

Normally, your configured local path is a clone of the repository you are bisecting, so whatever revision is locked in your lockfile should be present in your local copy and this should pose no issues, right?

I imagine you could run into this issue if your local clone is out of date and the revision in the lockfile pointing the repository clone is not yet present there. In that case, running git fetch on it should fix it, and that's probably better than ignoring the error since otherwise you might not be bisecting against up to date code anyways.

Let me know your thoughts.

[deivid-rodriguez]

Well shame on me for not properly reading the description of the PR. You explained the exact kind of situation where this setting could be useful (bisecting scripts that change the HEAD of the repo).