add targeting system and target command

[xrstf]

What this PR does / why we need it:
This PR introduces the "targeting" system from gardenctl v1, just slighly refactored. Targeting is used to free the user from having to specify the garden, seed and/or shoot name for most commands (e.g. free them from doing something like gardenctl ssh -g garden1 -s seed1 --ss shoot1 nodeNameXY). To achieve this, the user can use the target command and incrementally refine the goal for the upcoming commands, e.g.

gardenctl target garden mygarden
gardenctl target seed aws-seed
gardenctl target shoot my-shoot
gardenctl ssh nodeNameXY

The previous implementation chose to work with "stack"-like approach, however the new implementation uses a dedicated map instead. The code is also less generic, which seems like a downside, but if you look carefully at the v1 code, the generic parts were drowned in super specific hacks and exceptions and lots and lots of assumptions. That made the old code hard to read and understand:

// getKubeConfigOfClusterType return config of specified type
func getKubeConfigOfClusterType(clusterType TargetKind) (pathToKubeconfig string) {
	var target Target
	ReadTarget(pathTarget, &target)
	gardenName := target.Stack()[0].Name
	switch clusterType {
	case TargetKindGarden:
		pathToKubeconfig = TidyKubeconfigWithHomeDir(getGardenKubeConfig())
	case TargetKindSeed:
		if target.Target[1].Kind == "seed" {
			pathToKubeconfig = filepath.Join(pathGardenHome, "cache", gardenName, "seeds", target.Target[1].Name, "kubeconfig.yaml")
		} else {
			pathToKubeconfig = filepath.Join(pathGardenHome, "cache", gardenName, "seeds", getSeedForProject(target.Target[2].Name), "kubeconfig.yaml")
		}
	case TargetKindShoot:
		if target.Target[1].Kind == "seed" {
			pathToKubeconfig = filepath.Join(pathGardenHome, "cache", gardenName, "seeds", getSeedForProject(target.Target[2].Name), target.Target[2].Name, "kubeconfig.yaml")
		} else if target.Target[1].Kind == "project" {
			pathToKubeconfig = filepath.Join(pathGardenHome, "cache", gardenName, "projects", target.Target[1].Name, target.Target[2].Name, "kubeconfig.yaml")
		}
	}
	return pathToKubeconfig
}

The new v2 code makes no assumptions like that and simply has dedicated functions and fields for garden, seed, project and shoot.

Likewise, the new code separates the data and logic, with the Target interface only providing read access to target information, and the more complex logic being wrapped up in the Manager (so it's manager.GardenClient(target) instead of target.K8sClientForTarget(TargetKindGarden)). This is because we surely will rework the targeting in the future and this separation makes it easier to exchange the implementation.

I chose to provide controller-runtime clients, because I like their interface much better than the Kuberntes clientsets. One downside so far is that namespace targeting doesn't work yet, so targeting a project is currently pointless and returns a client to the garden cluster.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Release note:

Added `target` command

[gardener-robot]

@xrstf Thank you for your contribution.

[petersutter]

@xrstf there are some lint errors that need to be fixed, otherwise lgtm

[petersutter]

I just tested it locally and ran into an error because the home folder was not resolved for the garden kubeconfig.

cat ~/.garden/gardenctl-v2.yaml
gardens:
- name: my-garden
  kubeconfig: ~/path/to/kubeconfig.yaml 

[xrstf]

@petersutter linted and handled ~ in configuration now.

[petersutter]

prefer -session

do not understand

[xrstf]

Yeah I've removed the notion of "sessions" again now. The comment was .. inspired, yet misleading. I am not actually sure how we want to allow users to switch between targets (we probably want to offer that, but how exactly?), so it's probably best if we do it in another PR.

[petersutter]

/lgtm, let's get this basic target handling in and improve as we go