Add a "mr" command for checking out a merge request branch

[amateescu]

Checking out a merge request by hand means finding the issue fork, adding it as a remote, fetching, checking out the branch and re-solving the overlay. Skipping the last step is what produces Required package "drupal/core" is in the lock file as "11.x-dev" but that does not satisfy your constraint "12.x-dev" from ddev composer install.

ddev mr core 16853      # a merge request number
ddev mr core 3563677    # an issue number, resolved to its merge request
ddev mr token 136       # a contrib module's merge request
ddev mr https://git.drupalcode.org/project/drupal/-/merge_requests/16853
ddev mr https://www.drupal.org/project/drupal/issues/3563677

• Reads the merge request from the git.drupalcode.org API. The request runs in the container, so the host needs neither curl nor jq. The path and the jq filter are passed as arguments instead of being spliced into the command, so a pasted URL cannot inject anything into the container shell.
• The fork remote tracks only the merge request branch. A fork has a copy of every branch of the project it was forked from, and those copies are what make a later git switch 11.x ambiguous, so the refspec is narrowed instead of only the first fetch. A second merge request from the same fork is added to it. A remote set up by hand is left as it is.
• The branch tracks the fork, so a plain git push updates the merge request. --https gives a remote you cannot push to.
• core means whichever project is at the root, read from its remotes. ddev switch core now reads it the same way instead of assuming project/drupal. That is no change for a core root, but a distribution root no longer resolves core's remote as its canonical one.
• A contrib module is required at the dev version of the branch the merge request targets, because that is the release branch drupal.org publishes one for. Requiring the merge request branch itself cannot work, since the drupal.org repository is canonical and outranks the path repository, so Composer refuses to fall back to it. The code installed is the checkout, which composer-git-installer keeps in place.
• One consequence of that is worth knowing. A merge request that adds a dependency to the module's own composer.json will not have it installed, because the solve reads drupal.org's metadata rather than the checkout.
• An issue with several open merge requests is listed rather than guessed at. An issue whose only merge request is merged still checks out. A local branch that has diverged from the fork's is left alone with a note. A project that cannot be read is reported separately from a number that is simply wrong.
• Tests: the contrib happy path through a real Composer solve, all three alternate invocations, the fetch-scope assertion, five error paths, and a unit check that the root project is read from the remotes.