Accommodate for k8s.io api/apimachinery/client-go not using semver go mod paths

[garomonegro]

These k8s Clients/APIs are in v0.x.x and they can break contract/signatures at any time. They do not follow the Golang semantic import version standard for their go modules paths.. This causes dependency issues when projects that use them import Kubedog for their BDDs.

kubedog/go.mod

Lines 14 to 16 in 018e64a

	k8s.io/api v0.17.2
	k8s.io/apimachinery v0.17.2
	k8s.io/client-go v0.17.2

The discussion about this issue starts here. It contains some of the reasons why some of the k8s.io maintainers dont want to move to the standard.

Until the above issue is resolved, for each new release of Kubedog, we need to have several versions/tags that use different versions of these dependencies. Which ones or how? That has to be defined - maybe a CD would be needed for this, better testing as well.

[garomonegro]

In some, if not most cases, BDDs are independent of the codebase of the project. So we can propose that BDD related code is kept in an independent go module to avoid diamond dependency problems. BUT this does not solve the problem of users needing new/deprecated features available in the different versions of those deps.