Add reference type and container transports

[cgwalters]

Currently this crate faithfully tracks most of the image spec. However, there's some linkage between the image spec and the distribution spec; for example the image spec notes org.opencontainers.image.base.name and says

This SHOULD be image references in the format defined by distribution/distribution.

And in practice of course many tools that are using the image spec will also want to deal with distribution. Now, there is a Rust crate https://github.com/oras-project/rust-oci-client which contains a full client for distribution including a Reference type.

I'd like to propose that we import that reference type - but obviously not the full client code. (For me currently I am using https://github.com/containers/containers-image-proxy-rs which speaks the distribution bits via forking skopeo instead of reimplementing it, for the reasons enumerated in the git repo).

But it would make total sense for containers-image-proxy-rs to use a reference type defined here.

---

There's then another thing...today in the podman-associated set of projects in github.com/containers we also have the "containers-transports" bits that are an extension of references (e.g. docker://<reference> as well as oci:/path/to/dir:<reference>). Any objects to adding a parser for those here, corresponding to... https://github.com/containers/image/blob/0cade81948cafc0cd8f9dec5e3248b598bfdb7a0/transports/alltransports/alltransports.go#L27 I think? Except there's also code elsewhere that tries to heuristically accept both a reference and a transport+reference that we probably want too in Rust.

[cgwalters]

cc oras-project/rust-oci-client#159

[saschagrunert]

@cgwalters is this done?

[cgwalters]

First part is, but WDYT about the second part in the initial comment around the skopeo transports?

[saschagrunert]

@cgwalters yes I think having the transports side by side to the reference type would make sense.