Better convert dynamically bridged providers

[lunaris]

When converting Terraform code to PCL, a big part of the work is mapping Terraform resources and their providers to the equivalent Pulumi bits and pieces. There are a few parts to this process:

1. Given a Terraform provider P, what is the equivalent Pulumi provider?
2. When a Pulumi provider has been determined, what are the mappings we should use to turn the various resources, data sources, etc. under that provider into their Pulumi equivalents?

For part 1, we mostly use a hard-coded list -- the set of managed, first-class Pulumi providers is finite, and anything not in that list can be dynamically bridged. Armed with this, part 2 is reduced to the problem of asking the engine (which is calling us as the converter) for the right set of mappings. Until now this part has been broken in the presence of providers which we need to dynamically bridge: while we can generate the correct PCL, with appropriate package blocks that describe the plugins and parameterization required, we have not been able to pass the same information (e.g. parameterization) to the mapper. With pulumi/pulumi#18671, we now can! This change thus does that while tidying up a few other things around dynamically bridged/parameterized providers, and gets conversion in the presence of these providers a bit further along.

Note

Things are likely still not 100% perfect, since we use
required_providers blocks to work out the versions we'll pass when
parameterizing. In the case of converting state, we don't have these,
and it's not a given that we'll always have them when converting
programs either, but we can iterate from this base and hopefully close
these gaps quickly.

Blocked by pulumi/pulumi-terraform-bridge#2905 release 3.153.0

Fixes pulumi/pulumi#18187

[brandonpollack23]

I went through all of this and can't find much to say. This change was all very subtle, great work. I'm not certain I would have come up with this on my own at all.

[brandonpollack23]

just a reminder dont forget to remove

[tgummerer]

Not super familiar with this codebase, but the changes look reasonable to me. Could we add a test for this, or is this covered somehow already?

[Frassle]

Two comments.
Firstly echo @tgummerer this should have a test.
Secondly it would have been nice to do the go.mod updates thats caused the code churn and diagnostics to all change in its own PR for simpler review.