7238: Point to CoC which contains the contributor covenant r=deivid-rodriguez a=ajwann

### What was the end-user problem that led to this PR?

The generated README contains two different links to contributor covenant. Since the generated Code of Conduct *contains* the text of the Contributor Covenant, we can just point the generated README to the generated CoC, and explicitly refer to it as the code of conduct. 

### What is your fix for the problem, implemented in this PR?

The generated readme now points to the gems CoC (which contains the Contributor Covenant)

Closes #6905.

Co-authored-by: Adam Wanninger <ajwann@ajwann.com>

It sounds like this was mistankenly added in
4337a499d0108fc3748084934aaed7591b355a26. Then the forgotten MANPATH key
was added in bf5bf106230772934602768bb31a68dc925691f0, but this one
should've been removed I think.

7250: Fix ruby core dsl spec.rb failure, warning on build_metadata.rb r=deivid-rodriguez a=MSP-Greg

### What was the end-user problem that led to this PR?

Travis CI job on Ruby master was failing & had a nuisance warning.

### What is your fix for the problem, implemented in this PR?

1. dls_spec.rb - Minor change to the error msg regexp match string

2. build_metadata.rb - change `if @git_commit_sha` to `if instance_variable_defined? :@git_commit_sha`

Co-authored-by: MSP-Greg <msp-greg@users.noreply.github.com>

7249: Add `bundle package` functionality to `bundle cache` r=indirect a=deivid-rodriguez

### What was the end-user problem that led to this PR?

The problem was that the previous plan provided no migration path from the current `bundle cache` to the future one (an alias to `bundle package`).

### What was your diagnosis of the problem?

My diagnosis was that we should probably tell users first that in bundler 3, `bundle cache` will have a different implementation. However, after playing around with it a bit, I noticed that the additions to `bundle cache` provided by `bundle package` are fully backwards compatible. Or maybe I'm missing something but at least all `bundle cache` tests still pass when changing the implementation under the hood to use `bundle package`. As far as I can see, the only backwards incompatible change (start caching `git` and `path` gems by default) is already covered by the exisiting `cache_all` flag), so we should be good.

### What is your fix for the problem, implemented in this PR?

My fix is to remove the current implementation of `bundle cache`, and replace it with the current implementation of `bundle package`.

### Why did you choose this fix out of the possible options?

I chose this fix because it allows us to remove code and it reduces confusion about `bundle cache` vs `bundle package` making them work exactly the same.

On a future PR, I plan to clean this up so that everything (docs, code, tests) use `bundle cache`, and `bundle package` is left only as an alias. 

Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>

7248: Fix nested bundle exec's when bundler is a default gem r=deivid-rodriguez a=MSP-Greg

### What was the end-user problem that led to this PR?

The problem was that when bundler is a default gem, nested `bundle exec` commands generate a LoadError.

```
/home/travis/.rvm/rubies/ruby-head/bin/bundle:30:in `load': cannot load such file --
/home/travis/.rvm/rubies/ruby-head/lib/bin/bundle (LoadError)
```

### What was your diagnosis of the problem?

Not accounting for Bundler being installed as a default gem. When it's a default, the lib and exe folders do not share the same root folder.

This was the result of a change in https://github.com/bundler/bundler/commit/e742c3d5f458a4a59cf0eaab2567eca844f956d1 (#7100).

### Repo Example

Using Ruby master/trunk/ruby-head (as of https://github.com/ruby/ruby/commit/0c6c937904aafc1809386bd892a2d114d22d01fe), from a folder where `bundle exec` can be ran:

```
bundle exec "bundle exec 'ruby -v'"
```

### What is your fix for the problem, implemented in this PR?

Small adjustment to logic for finding the correct exe/bundle file.

### Why did you choose this fix out of the possible options?

I chose this fix because it's similar to previous code.

Fixes #7244.

Co-authored-by: MSP-Greg <msp-greg@users.noreply.github.com>

The additions of the `package` command are not actually backwards
incompatible, so we can do this transition without further care. All
existing specs of `bundle cache` pass when using the `bundle package`
implementation for it.

7239: Fully remove compatibility guard r=deivid-rodriguez a=deivid-rodriguez

### What was the end-user problem that led to this PR?

The problem was that this code is untested and never run.

### What was your diagnosis of the problem?

My diagnosis was that we can remove it.

### What is your fix for the problem, implemented in this PR?

My fix is to remove the code.

### Why did you choose this fix out of the possible options?

I actually intented to remove this in https://github.com/bundler/bundler/pull/6983, but after a discussing it with @simi I decided to keep it (see https://github.com/bundler/bundler/pull/6983#discussion_r259327593). After a second though I think this is safe to remove and that the potential use case (that the latest bundler is allowed to be installed by a really really old rubygems that didn't support ruby version constraints) is not a problem. The `required_ruby_version` constraint landed in [rubygems 0.6, 15 years ago](https://github.com/rubygems/rubygems/commit/240a9d3a3dc7211cad9680ce2579f502e215b519).

Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>