improve ssh command to work with not joined node

[KristianZH]

What this PR does / why we need it:
This PR fixes 2 issues:

• 1: Ssh for Azure did not work because Start Instance requires zone-id if we want
  automation. The same zone-id is required for aliyun ecs StopInstance
• 2: Now will be possible to SSH on node, which does not join the cluster.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:
@vpnachev @ialidzhikov @DockToFuture

Release note:

The `ssh` command now works with node name

[DockToFuture]

Would be also nice if we could reflect the ip address behind the node name in the gardenctl ssh cmd. In aws it is refelected in the node name but for aliyun, azure and gcp we don't see it in the output. Would be nice to add a separated output column to the cmd.

[vpnachev]

Would be also nice if we could reflect the ip address behind the node name in the gardenctl ssh cmd. In aws it is refelected in the node name but for aliyun, azure and gcp we don't see it in the output. Would be nice to add a separated output column to the cmd.

@DockToFuture this is possible only for machines that have the respective Node objects in the cluster.
Basically, I do not see why the internal IP is required. The flow should be as following:

1. gardenerctl ssh will work only for shoot clusters and it will take the name of the Machine object as an argument. It must not depend on the respective Node object because it may not exist.
2. gardenctl shell will work with any k8s cluster that has Node objects - e.g. seed, shoot, garden. It will use the names of the Node objects. Here the internal IP can be printed as some additional info, but I would not support the IP as an argument of the command.

[DockToFuture]

@vpnachev We never talked about the ip as an argument, we just want to print it to ease debugging.

[vpnachev]

Sure, but let it be only for gardenctl shell, not for gardenctl ssh.

[DockToFuture]

/lgtm

[KristianZH]

Sure, but let it be only for gardenctl shell, not for gardenctl ssh.

We discussed this suggestion with @DockToFuture and decided to not implement it for now, because there is no good approach for implementation.