tools/refenginediscovery: Refactor Ref-Engine Discovery library API

[wking]

Pull the UI portions of this out into tools/cmd, because the library API should not depend on urfave/cli.

The new refenginediscovery API is based on a per-configured-ref-engine callback, which gives callers lots of flexibility in how they want to handle each ref-engine and if/when they want to abort the protocol/host iteration.

I've also adjusted the ref-engine interface to return a new MerkleRoot type. This improves on the old Descriptor returns by:

• Being less opinionated about the root object, to stay in keeping with ref-engine-discovery.md's:

  The Merkle root may be a descriptor (media type application/vnd.oci.descriptor.v1+json), or it may have a different media type.

• Including the retrieval URI, which may be needed to expand references in the root object (e.g. if the root has a casEngines configuration which includes a relative reference).

These changes bring the API and output of the oci-discovery resolve … command much closer to the current Python module. The remaining differences are the presence of a roots indirection in the Python output (which I'm planning on removing) and the lack of uri entries for each root (which I'm planning on adding).

[wking]

The remaining differences are the presence of a roots indirection in the Python output (which I'm planning on removing)…

Actually, we may want to keep this. The Python implementation currently uses to pass through ref-engines-object-level casEngines. We may want to follow that lead in Go. There are alternatives, like injecting those casEngines entries into the MerkleRoot.Root object, but that gets tricky now that it's an interface{}. We can also add a new MerkleRoot.CASEngines and store the ref-engines-object-level entries (and any others we collect from other places) there.

[wking]

The Python UI is growing the uri entries in #25.

[wking]

Rebased around some recent changes with dc87b41 → 76a7635. I'm still not sure what the best way is to make this go get …able after #27, but at least with these changes we can compile the executable again ;).

[wking]

I think the vendor thing is grounds to create separe spec, lib, and CLI-tool repos. I'll work that up tomorrow.

[xiekeyang]

Sorry I am cognizant that #27 is a careless commit, which leads code structure some confusion. So I have reverted it #31 . We should figure out a better way later.

[xiekeyang]

I would help to resolve the conflicts now.

[xiekeyang]

I split commit https://github.com/xiekeyang/oci-discovery/pull/33/commits/f57ae08b4bac382513ce140e4550449c0af8849c to #33.

[wking]

Rebased around #31 with 881db73 → 9529456. With #31, we can continue to punt on splitting this out into separate repos.

[xiekeyang]

LGTM