Make "estargz" pkg import-friendly

[ktock]

Currently, the consumer of "estargz" pkg needs to go mod this project (that includes snapshotter & fs codes as well).
Because of that, there seem cases where a dependency cycle is created (https://twitter.com/mattomata/status/1337270338221064192).

@mattmoor Could you elaborate the current dependency cycle you are facing? Splitting out estargz to another project is a big change (approval is needed for creating a new repo under containerd) so we first would like to find a way to solve that dependency cycle in the current repository structure.

cc: @AkihiroSuda

[mattmoor]

Yeah, so I'd love it if this could be split into its own standalone module (a la compress/gzip). I don't mean upstreamed into Go itself, but at least keeping it neatly in its own module. I don't know a lot about nested go.mod, but that might be an option. 🤔

Context: I want to see us leverage this in some of the core utilities in google/go-containerregistry (aka GGCR): google/go-containerregistry#866

If GGCR needs to vendor something from stargz-snapshotter, then (at the go.mod level), we would have a cycle because you folks are using us here: https://github.com/containerd/stargz-snapshotter/blob/master/cmd/ctr-remote/commands/optimize.go#L54-L59

This might shake out ok now because pruning, but generally projects with cycles at the go.mod level end up in some sort of dependency hell. 😞

IDK yet whether this is blocking for GGCR prototyping, but I think it is something we should consider before merging that support regardless.

Just to reiterate here, I am a BIG fan of this work 🙏, and am poking everyone I can to pay attention, so if you think there are ways I can help support this, please reach out.

[ktock]

Closing this as estargz pkg is independently importable since #195.

[mattmoor]

Starting to pull it in here: google/go-containerregistry#870

thanks!