ClientContainer: Remove response timeout from stop (#667)

After the large reworks, I'm not as worried about having this timeout
anymore. Prior to the reworks stop was signaled via an async event sent
to the daemon as stop was performed directly on the given runtime-helper
instance. If anything errored during that it was common for things to
explode, but now that stop is:

client -> APIServer -> runtime-helper instance

and the logic for stop has been improved quite a bit, in addition to
stop no longer holding a lock during it's operation, I'm not sure we
need this. In the future it'd also be nice to support no timeout (the
timeout until we send SIGKILL, not response timeout) in which case we'd
have to have an extra bit of logic here to skip the response timeout in
that scenario anyways.

Package.resolved

@@ -1,5 +1,5 @@
 {
-  "originHash" : "23302f085b6239754a405a0a6ec0dcaad1d48086319c3eaa5a5650b4bf2670e5",
+  "originHash" : "a04bb1d08ef1fca925fcfe3250303675ad17c962fecc35b23972ebb8598bb63f",
   "pins" : [
     {
       "identity" : "async-http-client",

Sources/ContainerClient/Core/ClientContainer.swift

@@ -196,13 +196,7 @@ extension ClientContainer {
             request.set(key: .id, value: self.id)
             request.set(key: .stopOptions, value: data)
 
-            // Stop is somewhat more prone to hanging than other commands given it
-            // has quite a bit of `wait()`'s down the chain to make sure the container actually
-            // exited. To combat a potential hang, lets timeout if we don't return in a small
-            // time period after the actual stop timeout sent via .stopOptions (the time
-            // until we send SIGKILL after SIGTERM if the container still hasn't exited).
-            let responseTimeout = Duration(.seconds(Int64(opts.timeoutInSeconds + 3)))
-            try await client.send(request, responseTimeout: responseTimeout)
+            try await client.send(request)
         } catch {
             throw ContainerizationError(
                 .internalError,