SDK: should have better DX when initialized with disconnected platform

[jakedoublev]

Background

At present, calling sdk.New() with a platform endpoint that does not resolve to a connected platform resolves to a potentially misleading error: ErrPlatformConfigFailed (see logic).

This is misleading because it could mask legitimate platform errors:

1. config not being served but platform running
2. config served at wrong location but platform running
3. logic to get config is bad, but platform running

It would be better to test connection to a running platform during a remote connection (non-IPC) SDK instantiation within the sdk.New logic, and to return a more specific error ErrPlatformEndpointNotFound when the provided platformEndpoint does not resolve to a running platform.

This will clarify platform running states to PEPs, who are currently expected to write their own logic to detect ErrPlatformConfigFailed as the key error for an invalid or disconnected platform endpoint to provide the user with helpful information about checking the platform endpoint value or platform state (see otdfctl).

Acceptance Criteria

1. A small check is added before fetching the platform configuration within sdk.New to ensure the platform is actually reachable
2. If it is not reachable, a more helpful named error is provided to scope the issue to the platform likely not running at the provided endpoint

[jakedoublev]

In consultation with @dmihalcik-virtru, decided to implement via:

1. WithConnectionValidation constructor option
2. exposing a health check validation function from the sdk module for client consumption

If clients are using WithPlatformConfiguration at present to bypass the current connectivity check, we will not break them today with the intention to refactor code paths between IPC, remotely connected, and offline scenarios when the offline effort is picked up.