Move stacksplugin cache to .terraform.d

[Maed223]

Description

This PR moves the cached stacksplugin binary location to .terraform.d by default, with the option to override this location with the argument -plugin-cache-dir.

If this location is overriden, then the path provided is stored in .terraform/.stackspluginpath of the current working directory for future reference by the subcommand. The thought behind this was to be proactive with providing a workaround in the event any user specific issues made the default behavior a problem.

I figure no changelog entry is needed as this change wraps up into the existing entry for the terraform stacks subcommand.

Context

As it stands, when you run terraform stacks ... the stacks plugin binary is downloaded to the .terraform/tfstacks directory in current working directory. This is a pattern that came from the cloud subcommand that we ran with at the time. This made sense for the cloud plugin as the command needs the context of a cloud block (with a .terraform implicitly in the configuration directory) to fully function.

Though this isn't the case for the stacks plugin– many of it's commands pertain to cloud operations apart from the configuration itself (listing deployment runs, watching the progress of a deployment group, etc.). As such we didn't make this a requirement of the stacks command.

A consequence of this is that the stacks command has the potential to litter .terraform/tfstacks with the plugin binary outside of stacks configuration directories– and it seems likely considering the nature of many of the commands.

Testing

Running terraform stacks should create .terraform.d/stacksplugin with the stacksplugin binary.

Otherwise running terraform stacks -plugin-cache-dir=... should create stacksplugin at the provided cache location with the stacksplugin binary as well as a '.terraform/.stackspluginpath' in your working directory with the provided cache path override.

Target Release

1.13.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.