Rewrite Construct handling in line with Call

[iwahbe]

The interface provided by provider.Provider.Construct is extremely hard to work with and test against. The interface was "designed" during hack-week and was thus extremely rushed.

pulumi-go-provider/provider.go

Lines 1033 to 1044 in c63d6b6

	type ConstructRequest struct {
	URN presource.URN
	Preview bool
	Construct func(context.Context, ConstructFunc) (ConstructResponse, error)
	}
	type ConstructFunc = func(
	*pulumi.Context, comProvider.ConstructInputs, pulumi.ResourceOption,
	) (pulumi.ComponentResource, error)
	type ConstructResponse struct{ inner *rpc.ConstructResponse }

Downsides are:

• Provider authors are never given access to the raw resource.PropertyMap inputs and outputs.
• The interface is confusing to use, it's a lambda on a input which must be called to return the output.
• Not compatible with rpc.Provider interop: Support Construct calls on rpc.Provider #219
• Not compatible with test mocking: Allow Component Resources to be tested with integration #82

provider.Provider.Call has a lot of the same constraints, but a much more reasonable interface:

pulumi-go-provider/provider.go

Lines 815 to 832 in c63d6b6

	// CallRequest represents a requested resource method invocation.
	//
	// It corresponds to [rpc.CallRequest] on the wire.
	type CallRequest struct {
	Tok tokens.ModuleMember
	Args presource.PropertyMap
	Context *pulumi.Context
	}
	// CallResponse represents a completed resource method invocation.
	//
	// It corresponds to [rpc.CallResponse] on the wire.
	type CallResponse struct {
	// The returned values, if the call was successful.
	Return presource.PropertyMap
	// The failures if any arguments didn't pass verification.
	Failures []CheckFailure
	}

Note that Call has the same set of constraints as Construct, but there was more time spent doing design work.

To make it easier/possible to support #82, #219 and #266, we should re-write Construct in the same style as Call.

This will be a breaking change, so it must go in before 1.0.0. This should not effect infer based component, since they are authored at a higher level. It will effect how infer implements components, and will enable better error messages (or even fixes) to issues like #270.