This allows for specifying the lockfile to read and write. It mirrors
the --gemfile option, and has higher priority than the lockfile
method in the Gemfile. It also mirrors the bundle lock --lockfile
option.

When the --lockfile option is used, it is applied twice. First, before
the Gemfile is read, to specify the lockfile to operate on, and again
after the Gemfile is read, so that if the Gemfile has a lockfile
method that overrides the defintion's lockfile, the --lockfile option
still has higher precedence.

https://github.com/ruby/rubygems/commit/17acdd4a89

This allows for the same behavior as including `lockfile false`
in the Gemfile. This allows you to get the behavior without
modifying the Gemfile, which is useful if you do not control the
Gemfile.

This is similar to the --no-lock option already supported by
`gem install -g Gemfile`.

https://github.com/ruby/rubygems/commit/6c94623881

Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>

https://github.com/rubygems/rubygems/commit/ccb65ce0ea

https://github.com/rubygems/rubygems/commit/573ffad3ea

For synopsis, subcommand and flag documentation like other commands do.

https://github.com/rubygems/rubygems/commit/f528029756

I realized `--redownload` is not a good name, because it does not
necessarily redownloads gems. It only forces reinstallation even if gem
is already installed.

So I believe `--force` is actually a better name and the introduction of
`--force` was a misunderstanding of what the `--force` flag did at the
time.

Let's cancel the deprecation of `--force`.

For now the `--redownload` alias is left around until we decide what to
do with it.

There already different ways of toggling off this behavior, like setting
`bundle config clean false`, or configuring Bundler to install to system
gems with `bundle config path.system true`.

https://github.com/rubygems/rubygems/commit/6daa09f60a

https://github.com/rubygems/rubygems/commit/3e4687616a

https://github.com/rubygems/rubygems/commit/9ed20bddab