Deprecate NewClient, add Dial and NewLazyClient and CheckHealth

[cretz]

What was changed

Mostly what's at #793 w/ slight changes.

• Add client.Dial which eagerly connects like NewClient does
• Add client.NewLazyClient which doesn't connect until you make a call
• Deprecate NewClient
• Make sure server capabilities are lazily fetched before each high-level call and before worker start if they are not already fetched
• Add client.Client.CheckHealth call

Why?

People want lazy-connecting clients but we still need capabilities checks. People also wanted explicit health checking.

Checklist

1. Closes Deprecate NewClient, create Dial, NewLazyClient, and CheckHealth calls and support laziness #793
2. Closes Allow lazy connection on client #753
3. Closes Expose health check on WorkflowClient #595

[alexshtin]

I'd avoid words "we" and "I" in comments. Something more "dry" is better here:

Suggested change

	// We intentionally don't "ensureIntialized" here because there is no direct
	// error return path. Rather we let GetWorkflowHistory do it.
	// "ensureIntialized" is not called here intentionally because there is no direct
	// error return path. GetWorkflowHistory will do it.

[alexshtin]

Suggested change

	return internal.DialClient(options)
	return internal.Dial(options)

?

[cretz]

Just Dial in a client package makes sense, but just Dial in an internal package where you could be dialing other things does not. worker.New -> internal.NewWorker, client.Options -> internal.ClientOptions, etc, etc.

[mmcshane]

I'm okay with it because the functionality is there but I had different expectations.

I had understood that all SDKs would move to become lazy by default with an option to be eager and thus I expected Dial to be lazy and NewClient to remain eager (to be kind to existing callers who might expect certain behavior). Not sure that NewLazyClient pulls its own weight in terms of utility versus adding to the API surface area.

[mmcshane]

Curous if you considered taking this opportunity to move to function-style optional args?

[cretz]

For most of the Go SDK, the struct options is good enough to still give us future proofing. There's little benefit of a func Dial(options ...DialOption) (Client, error) over struct-based if you 1) have no other params, 2) don't need to preserve backwards compatibility, and 3) can reasonably copy the struct.

I could be leaving off an important benefit, so if there is a good enough argument I'd definitely reconsider.