This helps with navigating ambiguity around the word backend. The new name should indicate that the value represents a `backend` block, not a more general interpretation of what a backend is.

…to a lack of data. Don't change it if pluggable state storage is in use.

…sing that data when creating a plan file.

… state storage

…ly isn't valid for `stateStoreConfigState` to be nilI'm about 90% sure that backendConfigState being nil is ok <_<

… file with the expected state_store configuration data

…ng it to prepare a Local backend that uses the state store

… plan file

…an file to configure and use a state store

…e full init-plan-apply workflow

…quired providers, if PSS is in use.See the code comment added in this commit. This addition does not impact an apply command as the missing provider will be detected before this code is executed. However I'm making this change so that the method is still accurate is being able to return a complete list of providers needed by the plan.

…or state store config when getting a backend from a planfile

…Backend, so the planfile's Backend struct isn't flagged as empty.

… the Backend config are set

…f a backend or state store is completeThe alternative approach would be to change the existing `Backend` field in the `Plan` struct to be a pointer. I'm open to either option, but the approach of using an `Empty` method matches existing work in the `workdir` package when inspecting the backend state file, and that seems a similar use-case to inspecting the plan file.

…e store is complete when reading or writing a plan file