Fix `[patch]` sections depending on one another

Fix `[patch]` sections depending on one another

This commit fixes a bug in `[patch]` where the original source is updated too
often (for example `Updating ...` being printed too much). This bug occurred
when patches depended on each other (for example the dependencies of a resolved
`[patch]` would actually resolve to a `[patch]` that hadn't been resolved yet).
The ordering of resolution/locking wasn't happening correctly and wasn't ready
to break these cycles!

The process of adding `[patch]` sections to a registry has been updated to
account for this bug. Instead of add-and-lock all in one go this commit instead
splits the addition of `[patch]` into two phases. In the first we collect a
bunch of unlocked patch summaries but record all the `PackageId` instances for
each url we've scraped. After all `[patch]` sections have been processed in this
manner we go back and lock all the summaries that were previously unlocked. The
`lock` function was updated to *only* need the map of patches from URL to
`PackageId` as it doesn't actually have access to the full `Summary` of patches
during the `lock_patches` method.

All in all this should correctly resolve dependencies here which means that
processing of patches should proceed as usual, avoiding updating the registry
too much!

Closes #4941