Create a git commit for each selected gem update when --commit is specified

[mattbrictson]

Sometimes, updating gems can lead to bugs or regressions. To facilitate troubleshooting, this PR introduces the ability to commit each selected gem update in its own git commit, complete with a descriptive commit message. You can then make use of tools like git bisect to more easily find the update that introduced the problem.

To enable this behavior, pass the --commit option:

bundle update-interactive --commit

The gems you select to be updated will be applied in separate commits, like this:

* c9801382 Update activeadmin 3.2.2 → 3.2.3
* 9957254b Update rexml 3.3.5 → 3.3.6
* 4a4f2072 Update sass 1.77.6 → 1.77.8

Supersedes #50 and #51. Closes #49.

[mattbrictson]

🗒️ The integration tests now need to run actual git commit commands. In order to create commits, git must be configured with a user name and email.

[mattbrictson]

🗒️ apply_updates now returns a Hash of the gems that were actually updated. We use this to create a commit message that describes what gem was updated. There are some rare edge cases to consider:

1. Nothing was actually updated. This happens when bundler says "Bundler attempted to update [GEM] but its version stayed the same." This is because sometimes gems can't be updated individually and must be updated together. In this case we skip the gem and don't commit.
2. More than 1 gem was updated. For example, if we are updating rails, several other gems like railties, etc. are implicitly updated. For the commit message, we only care about the gem we explicitly asked for; rails in this case.
3. Gems other than the one we requested were updated. This is an edge case within edge case (1). Bundler might fail to update the gem we asked for, but still update one of the gem's sub-dependencies. I have seen this happen with rubocop and rubocop-ast. In this case, we will still create a commit; the commit message will contain the actual gem that was updated as opposed to the one we asked for.

[mattbrictson]

@jaredmoody if you have a few minutes, could you review this PR? This will supersede the proof-of-concept (#50, #51) that we discussed previously.

[jaredmoody]

LGTM, seems more robust than what I wrote :P