command/meta: Fix PSS migration during provider upgrade

[radeksimko]

This ensures that the correct (old) provider is used to read the old state(s).

As discussed internally we'll need to still address the end-user migration paths to avoid relying on the backend state file always being there.

IMHO some of the codepaths will likely look the same as I'd expect us to want to avoid allowing multiple versions of the same provider in the lockfile.

I assume there will still be the concept of PreviousLocks being passed around - perhaps we'd make the names migration-specific but I'm not sure. The problem of schema caching is still relevant too.

Target Release

1.16.x

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[SarahFrench]

I've taken a look and left some comments. I'm going to ask internally for advice about how to handle the provider cache issue.

Also, while debugging I found some fixes needed for diagnostics: #38275 . It could be worth cherry-picking the change into your branch or rebasing once it's merged.