This allows communication with a grpc server that is listening
on the HTTP/2-over-UDS scheme.

UDS sockets compared with loopback TCP:
* UDS needs no loopback IP interface
* UDS can use filesystem-based access control
* UDS has no TCP/IP stack encapsulation overhead
  (higher throughput, less CPU use depending on use-case)
* For UDS, the HTTP/2 pseudo-header `:authority` needs a workaround,
  as the hostname is not a string but a tuple, and it may contain
  nul or slash characters which are not valid to send as values.
  The grpc-go client implementation sets the `:authority` to
  the hardcoded string `"localhost"`, so that behavior is followed,
  see grpc/grpc-go#3730

If the `{local, UnixSockPath}` tuple is passed along
from grpcbox to chatterbox, then the functionality
is working well, so there is not much impact on grpcbox aside
from updating the `:authority` field appropriately.

Note: the UDS usage is not documented in `chatterbox`,
their spec says that the host must be type `string()`
but it causes no issues with their library if that is not the case,
as they just pass the value through to `gen_tcp`
which supports the unix socket notation.