**What this PR does / why we need it**:
Visibility rules allow dependency control. The rules currently in
place make all targets public, to override the default state of
private. This PR removes public visibility from kubectl code. It
uses specially named pacakge groups to identify "bad" dependencies on
kubectl code for later refactoring or removal.
**Which issue this PR fixes**
First in a series of PRs to address kubernetes/community#598
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Use munged semantic version for side-loaded docker tag
**What this PR does / why we need it**: rather than using the md5sum of the dockerized binary for each side-loaded docker image, use the semantic version (with `+`s replaced with `_`s) for the side-loaded docker images.
The use of the md5sum for the docker tag dates to #6326 2 years ago. I'm not sure why that was chosen, short of it being fairly unique.
My main motivation for changing this is that it makes building the docker images using Bazel's docker rules easier, since the semantic version doesn't depend on the build output.
An added benefit is that the list of images on a running kubernetes cluster is also more straightfoward; rather than a list of opaque, meaningless hexadecimal strings, you get something that indicates the provenance of the image. It'd also be clearer that all of the images came from the same build.
I was able to start a cluster with this change on GCE using both `make quick-release` and `make bazel-release`.
Note that this change has no effect on the tag that's pushed to gcr.io during releases; that's still controlled via `KUBE_IMAGE_DOCKER_TAG`, though we may want to merge this functionality at some point.
@kubernetes/sig-node-pr-reviews is there any reason to stick with using the md5sum strategy? @dchen1107 do you remember why we went with md5sums originally?
cc @spxtr @mikedanese
**Release note**:
```release-note
```
