refactor: externalize NewFrameworkProvider as we do with SDKv2 Equinix Provider for easier downstream Pulumi provider

[ocobles]

Comparing our Pulumi and Terraform provider to the Talos provider and their effort to work with an internal/ provider, siderolabs/terraform-provider-talos#130, I see that Talos had internalized the provider and needed to revert that to simplify the shimming.

Looking at how the Pulumi providers wrap the SDKv2 and Framework providers, it appears that this is the only resource from TF that they depend on -- the provider objects.

For example:
https://github.com/pulumiverse/pulumi-talos/blob/main/provider/resources.go#L35

Our SDKv2 Provider is exposed today as equinix.Provider. We intentionally left this object in an exported package because of the dependency that Pulumi and Crossplane (at the time) had on this object.

Looking at the Equinix TF provider, I think within equinix/provider.go we can export a framework provider function (name doesn't matter -- equinix.NewFrameworkProvider(version, ua string)?) that effectively calls on https://github.com/equinix/terraform-provider-equinix/blob/main/internal/provider/provider.go#L27C1-L32C1

The Pulumi Equinix shim would take the return value of that function. With the New... function exported and taking user-agent as an argument, we wouldn't need the submodule, shim patch, or the UA patch.

Originally posted by @displague in equinix/pulumi-equinix#79 (comment)

[ctreatma]

Based on the difficulties we ran into with refactoring provider resources into isolated packages, we probably don't want to (and maybe can't) tie the framework provider back into the equinix package/directory.

I'm hesitant to introduce a public interface to satisfy Pulumi--and thus establish that there is some broader validity in consuming this provider as a Go module rather than a plugin binary--but if we do go that route, we should introduce a new package for that purpose and hide both the SDK and framework providers behind it.

[displague]

if we do go that route, we should introduce a new package for that purpose and hide both the SDK and framework providers behind it.

Cyclical dependencies have been a concern with the refactor. That would make sense.