[Investigation] Remove Containerd dependency from root go.mod

The containerd/containerd repo brings in quite a lot of transitive dependencies for what we actually use the import for. We currently use it for the task definitions, error definitions and a couple of other things for our shim that's built out of this repository. If the shim had it's own go.mod this may be alleviated, although with adding a bit of annoyance to maintenance.

A real pain point of this however that we'd encountered in the wild is when trying to update kubernetes/kubernetes to a new tag of hcsshim, which was that Containerd 1.5+ (before 1.5 containerd was not on go modules) currently errors out when trying to get vendored into k8s. This is due to Containerd having dependencies on a lot of the k8s subprojects that live in the staging directory in kubernetes/kubernetes and the projects in the staging directory having dependencies on each other through replace directives. I'm not sure of the root problem here or what's the best solution long term, but for our case removing this dep from the root go.mod will solve quite a lot.

Containerd has already done some work to try and alleviate some scenarios where the only thing you might need from Containerd is just api definitions, see https://github.com/containerd/containerd/pull/5716 (thanks @dims!!!) but we use the dep for a bit more than what this change offers.

Perhaps there can be some work done in kubernetes itself to alleviate some of these issues, as it doesn't seem uncommon to have a project that depends on some of the subprojects that needs to be vendored into k8s itself. I've made a dead simple repo that just depends on a couple of the sub projects at the same tags that ctrd 1.5 was on, and the same issue arises on trying to add this as a dependency to K8s https://github.com/dcantah/deps.

Start with the root go.mod and the imports used by cmd/containerd-shim-runhcs-v1, then inspect the containerd dependency and its transitive modules. Determine whether the shim can retain the task and error definitions without the root dependency, and verify that Kubernetes vendoring no longer encounters the described replace-directive conflict.