Bound connection pool background dials to configured dial timeout

[LINKIWI]

This PR is mildly related to #3088.

Callsites within the connection pool implementation that start asynchronous/background connection dials (for example, adding an idle connection to fulfill the required minimum idle connection count) currently use a background context for the dialer.

This has two problems:

1. It can cause dial goroutines to have unbounded lifetime, subject only to the error behavior of the dialer implementation.
2. Due to the bug described in Eliminate redundant dial mutex causing unbounded connection queue contention #3088, this callsite contends with other dialer invocations. In particular, this means that the background operation of adding a new idle connection can block critical-path connection acquisition.

This PR proposes threading the existing dial timeout through from top-level options to the connection pool, and using that value as a timeout bound on the asynchronous dial operation.

[sgp]

I know it's a bit late now that it's in the released code, but won't this change inside of tryDial start saving context.DeadlineExceeded errors into the last dial error on timeout? While I have not tested this personally, it's reasonable to think that because the context with a deadline of cfg.DialTimeout is created before the dialer is initiated, that the context's deadline will fire first (or be racy).

While this change this is a reasonable "belt-and-suspenders" approach to ensuring the timeout is enforced and not reliant on the dialer implementation, I think there will be confusion if the errors change from the client user's perspective, as the error will reference a context that is totally opaque to the end user of the library.