nested go.mod may not be suitable

[vbatts]

with #283 we landed ./specs-go/go.mod.

The motivation to put it nested was to avoid pulling in deps that have nothing to do with the bare structures of the spec.
But this model with modules is tricky. And even in the opencontainers/image-spec#883 we found it simpler to just have the top level go.mod, rather than messing with a git-tag workflow, etc.

One other point, is it seems some tools like gopls do not easily handle nested go.mod files 🤷 :

[BenTheElder]

go.work in 1.18 makes this easier while retaining the separate dependency sets.