Fixes #16876

The pulumi provider protocol gRPC always starts by calling CheckConfig and then Configure. The problem is that CheckConfig accepts a property bag, which could contain secrets or outputs or resource references, etc. However, the engine doesn't know if the provider supports these items (and vice versa) until Configure is called, since Configure is the call where the engine and the provider agree on which parts of the protocol they support.

This introduces a Handshake component to the provider protocol that establishes which version of the protocol the provider and engine support. This also adds the plugins root and program directories to that handshake request allowing a provider to know where it was started up from. This also replaces Provider.Attach as the handshake request includes the engine address to connect to.

Tasting notes:

• Add Handshake with request/response to the protocol. Handshake starts as a high watermark for accepts secrets, accepts resources, etc but includes the plugins root and program directories (if possible), as well as the engine address. This pretty much replaces the need for Attach.
• Modify dialPlugin (where the engine establishes gRPC connections to plugins) to take a callback that is used to initialise the connection
• For non-provider plugins, pass testConnection, which captures the logic we have today -- call a dummy gRPC method and observed not implemented error to confirm connection is live
• For provider plugins, pass handshake, which sends a Handshake and captures the response
• All providers thus handshake at boot, as opposed to Configure, which a. happens later and b. is asynchronous
• Modify provider implementation to track a protocol; move acceptSecrets and company from configSource to there
• If Handshake is implemented, populate protocol on dialPlugin. If not, fallback to populating in Configure
• Invariant: Configure implies protocol
• The rest is largely plumbing
• We can add similar Handshake methods for the other plugin types as well