Fix diagnostic & avoid variable override via environment

[radeksimko]

Fixes #36410

It turns out the ordering of variable source evaluation is correct, it's just the diagnostic message that is wrong due to mixed ordering of arguments to fmt.Sprintf.

While the original report in #36410 suggests overriding variables via environment variables to be silently ignored, I think we cannot just make the same argument as was made in #36180

Specifically - We cannot expect users to be deleting autoloadable tfvars files. I do think it's reasonable to expect them to unset environment variables between plan and apply. Also, more importantly we only raise the diagnostic when values differ anyway.

That said after some consideration I chose to propose a warning that is still somewhat ignorable, just possibly noisy. I believe that is a good compromise that will not break workflows but still highlight what we consider anti-pattern.

Target Release

1.11.x

CHANGELOG entry

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

[jbardin]

I think this is going to be OK, and will help users going forward, but we should still be on the lookout for any existing workflows which might be impacted.

[jbardin]

I don't think we're planning on any more v1.10 releases, so we might not want that backport label

[radeksimko]

I don't think we're planning on any more v1.10 releases, so we might not want that backport label

I don't have strong opinion but I assume that it's technically a regression, i.e. this worked fine in 1.9 and we (using your words 😄) broke it in 1.10 so I also concluded it would be good to fix that.

We could also nudge people to upgrade I guess but we have not even cut a final 1.11 yet.

Either way the backport can be sorted out post-merge.