Make the lock command not be affected by the frozen setting

[deivid-rodriguez]

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

The lock command is specifically designed to manage the lockfile, so running it should take precedence over any "frozen" setting.

Besides that, "frozen" is not specifically designed as "lockfile cannot be updated" but as "installation of gems should be prevented if gemfile is not in sync with the lockfile".

The lock command does not install any gems and preserves the property of the lockfile being in sycn with its gemfile, so I think frozen should not influence it.

The current behavior is quite confusing when frozen is set. On an app where rubocop can get lockfile updates

```
$ bundle lock --update rubocop
Writing lockfile to /path/to/Gemfile.lock
```

Completely silent, it makes you think that it has written the lockfile, but still no updates.

In verbose mode, it gives a bit more information, but still confusing and unexpected, and does not change the lockfile:

```
$ bundle lock --update rubocop --verbose
Running `bundle lock --update "rubocop" --verbose` with bundler 2.4.20
Frozen, using resolution from the lockfile
Writing lockfile to /path/to/Gemfile.lock
```

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

With this commit, it updates the lockfile as expected, by ignoring the frozen setting during bundle lock.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[indirect]

This is great, thank you!

[deivid-rodriguez]

Thanks @indirect!

I included a refactoring that I don't think it's strictly related to this improvement, and while I think it's pretty nice, it does change the signature of a public method in Bundler::Definition, so I fear it might break some usage. In particular, I'd like to check if it could affect https://github.com/Shopify/bootboot.

So, I think I'm going to remove that change from this PR and consider it separately (whether it's fine, needs a deprecation or whatever).

Not that I consider this particular Bundler::Definition#lock method as public, but I also don't want to break people's code.

[martinemde]

@deivid-rodriguez I like the refactor and understand not wanting to break things. I think a deprecation warning makes sense given the code in bootboot. However, I think this refactor will be appreciated. It may even help the problem they're solving by patching Definition.new (but I didn't dig any further to see why or how that's used).

[deivid-rodriguez]

@martinemde I fully agree with everything you said. I suspect this refactoring would allow bootboot to remove some Bundler monkey patches which would be good for everyone.

I'll move the refactoring away from this PR and propose it separately in a smoother way (with deprecation).