Support registry fallback chains

[magnalite]

This PR adds support for registry fallback chains. See #34

To support sourcing packages from multiple registries each registry can elect a list of other registries which can be looked at as additional sources of packages. The primary use case is to enable us to create registry which contains packages that depend on packages in another registry, for example a private registry with packages depending on the public registry.

This PR includes significant restructuring of the test registry. Previously tests completely ignored the registry listed in the test package manifest files which isn't acceptable to test this sort of use case. Due to this, the tests have been shifted around and manifest files are now respected, even in tests.

As example we can see a new example test package's manifest

[package]
name = "private/private-with-public-dependency"
version = "0.1.0"
license = "MIT"
realm = "server"
registry = "test-registries/tertiary-registry"

[server-dependencies]
Minimal = "biff/minimal@0.1.0"

Where the manifest for biff/minimal contains

[package]
name = "biff/minimal"
version = "0.1.0"
license = "MIT"
realm = "server"
registry = "test-registries/primary-registry"

These belong to two different registries, primary-registry and tertiary-registry. The tertiary test registry contains the following index/config.json.

{
  "api": "http://localhost",
  "fallback_registries": ["../primary-registry"]
}

Tests look at all of these manifests and correctly resolve packages across multiple registries like this. I see this as a significant increase in the robustness of our integration testing. This also works against a real registry using GitHub/hosted api.

This PR:

• Rearranges the test registry to support multiple test registries
• Uses test package manifests to direct registry lookup rather than ignoring them and using a de facto test registry
• Adds a fallback_registries field to the index config.json
• Implements constructing a package source list by inspecting registry fallbacks
• Searches through sources in that source list during package resolution until candidates are found
• Improves error message for when a package candidate cannot be found
• Indicates which index is being looked at when updating local copies

[evaera]

Left some comments.

We should implement fallback chains for the in-memory registry so we can write more tests. One test I'd like to see is installing, then a registry closer to the front of the chain adds the same package.

Also, I didn't leave comments for the match statements matching on true/false, but we should convert those to if expressions as well.

[evaera]

Can we use anyhow::bail here? There's no reason to panic since this is already a fallible function

[magnalite]

Is there something wrong with a panic here? I'm not sure I understand why a bail would be preferable to a panic since this is code that shouldn't be running anyway. I like how the todo! here implies that this is something that needs to be implemented rather than some condition that hasn't been met.

[magnalite]

We should implement fallback chains for the in-memory registry so we can write more tests. One test I'd like to see is installing, then a registry closer to the front of the chain adds the same package.

I agree with this however I'm going to add it as a new issue. It's something we can always come back to and I'm eager to get this change finally merged.