doc: standardize on "host name" in async_hooks.md

Our docs have a mix of "hostname" and "host name" in prose.

Let's follow the usage of Unix man pages, RFCs, and most
professionally-edited sources, and use "host name" in prose and
"hostname" to refer to the command and in code.

Lint rule forthcoming.

PR-URL: #31326
Refs: #31073
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Richard Lau <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Trivikram Kamat <[email protected]>

doc/api/async_hooks.md

@@ -296,7 +296,7 @@ of propagating what resource is responsible for the new resource's existence.
 `resource` is an object that represents the actual async resource that has
 been initialized. This can contain useful information that can vary based on
 the value of `type`. For instance, for the `GETADDRINFOREQWRAP` resource type,
-`resource` provides the hostname used when looking up the IP address for the
+`resource` provides the host name used when looking up the IP address for the
 host in `net.Server.listen()`. The API for accessing this information is
 currently not considered public, but using the Embedder API, users can provide
 and document their own resource objects. For example, such a resource object
@@ -383,8 +383,8 @@ Timeout(7) -> TickObject(6) -> root(1)
 ```
 
 The `TCPSERVERWRAP` is not part of this graph, even though it was the reason for
-`console.log()` being called. This is because binding to a port without a
-hostname is a *synchronous* operation, but to maintain a completely asynchronous
+`console.log()` being called. This is because binding to a port without a host
+name is a *synchronous* operation, but to maintain a completely asynchronous
 API the user's callback is placed in a `process.nextTick()`.
 
 The graph only shows *when* a resource was created, not *why*, so to track