Bind to localhost rather than all interfaces (0.0.0.0)

[nfelt]

This tracks changing the default behavior value of TensorBoard's --host flag to localhost, rather than binding to all interfaces (aka 0.0.0.0 for IPv4 or :: for IPv6).

This is a more conservative default behavior since it exposes the webserver only to the user's machine. Users who specifically want to expose TensorBoard (e.g. in a lab context to let other users access the instance) can either pass --host=<interface> explicitly to bind to the desired interface, or configure some type of proxied access (for example, ssh port forwarding like ssh -L 6006:localhost:6006 <my-tensorboard-server>).

Strictly speaking the default behavior is actually to attempt to bind to :: and enable IPv6-mapped IPv4 for the socket, so that the same socket can serve both IPv4 and IPv6 traffic, which useful in cases where a hostname for the server (including sometimes localhost itself) has both IPv4 and IPv6 addresses associated with it, since this prevents spurious connection-denied errors from having chosen the wrong protocol. See #1449 for the details.

Since the existing behavior can't be achieved by specifying either 0.0.0.0 or :: explicitly, I propose that we accept an additional special host value, --host=*, which behave as though :: was passed but attempt to make the socket dual-bind to IPv4 as well.

This change should mostly resolve the following issues:

• Tensorboard could not bind to unsupported address family :: #1713 (bug still exists, but won't be triggered except on passing --host=*, and can be resolved by passing --host=0.0.0.0 instead)
• Tensorboard 0.0.0.0:6006 cannot work On Win7 but localhost:6006 works #89 (localhost will work)
• PR Confirm that the connection to tensorboard works or change to localhost #2371 (with defaulting to localhost, a potentially-not-reachable domain name will only be emitted when explicitly passing --host={0.0.0.0,::,*} and can be resolved by passing a domain name for an interface known to be valid; this PR could still be useful but the incidence of the issue should be much lower)
• Needing to click through the mac OS network security popup

[nfelt]

Duplicate of #2387

[nfelt]

Closing since I belatedly realized there is already a user issue for this.