feat(essentials): add enableMergeConflictPrompt configuration setting

[mhassan1]

What's the problem this PR addresses?

Merge conflict auto-fix is a handy feature, but it doesn't give the user much control over how it works. For example, there may be cases where the user would prefer to favor one lockfile variant over another, instead of combining all of them. Consider the following scenario:

1. User A upgrades all instances of library X in the lockfile to the latest version (1.2.0), on the main branch
2. User B upgrades all instances of library X in the lockfile (e.g. using yarn dedupe) to a later version (1.1.0), but not the latest version, on a branch
3. User B sees merge conflicts on a pull request from their branch to main
4. User B runs git merge main on their branch, sees the conflicts
5. User B runs yarn to resolve the conflicts, which combines both lockfile variants and, because of how Yarn resolves the similar lockfile entries, ends up with all instances of library X in the lockfile on version 1.1.0

While this outcome results in a technically correct lockfile, it is not the outcome that user A wants to see, since they upgraded all instances of library X to 1.2.0 for a good reason.

This PR gives user B more control over how merge conflicts will be resolved, which will make user A happy.

How did you fix it?

This PR adds a new enableMergeConflictPrompt configuration setting to .yarnrc.yml; when set, and Yarn detects merge conflicts in the lockfile, Yarn will prompt the user about how they want the merge conflicts to be resolved:

• combine: Combine the lockfile variants, which is the current behavior
• current: Use the lockfile on the current branch (HEAD)
• incoming: Use the lockfile on the incoming branch (MERGE_HEAD or REBASE_HEAD or CHERRY_PICK_HEAD)

Checklist

• I have read the Contributing Guide.
• I have set the packages that need to be released for my changes to be effective.
• I will check that all automated PR checks pass before the PR gets reviewed.

[mhassan1]

I am leaving this branch in draft status to collect general feedback, and to figure out how to write automated tests for this.