kubelet: Use os.Hostname() to get the system hostname

Currently the kubelet command executes the external hostname
command with the -f flag in order to get the fully qualified
hostname of the system. This is not reliable and does not
work correctly on all Linux platforms, even when the FQDN is
set correctly.

For example, on CoreOS the proper way to set the hostname
is by updating the /etc/hostname file or running the following
command:

    sudo hostnamectl set-hostname standalone.example.com

Both methods of updating the hostname result in a /etc/hostname
file with the following contents:

    standalone.example.com

Running the hostname command we get unexpected results

    hostname
    standalone.example.com

    hostname -f
    hostname: Unknown host

The above results are related to how the hostname is handled
on systemd based distros. The recommended way to get the
hostname is to use the hostnamectl command:

    hostnamectl
		   Static hostname: standalone.example.com
			 Icon name: computer-vm
			   Chassis: vm
			Machine ID: ffdb68e30b03488ebe746b38db2a934f
			   Boot ID: 02badde8679c443db990d538c3621ab3
		Virtualization: vmware
	  Operating System: CoreOS 379.3.0
				Kernel: Linux 3.15.5+
		  Architecture: x86-64

To get just the hostname use the --static flag:

    hostnamectl --static
    standalone.example.com

It should also be noted that some users will naturally want
to avoid setting the domain on a system and instead rely on
DNS search domains commonly configured in /etc/resolve.conf.
The current kubelet command does not permit this use case.

Resolve these issues by using os.Hostname() which handles the
hostname properly across all Linux distros. If the FQDN is set
os.Hostname() will use it by default. Using os.Hostname()
enables the use case where users prefer to omit the domain and
rely on DNS search domains.

As a fallback option use the existing -hostname_override flag
to set the hostname explicitly.

This patch introduces a change in behavior. Previously on
systems where the kubelet service failed to start due to the
inability to get the FQDN will now start up successfully and
use the hostname reported by the system.