backend/remote: Fix version check when migrating

When migrating state to an existing Terraform Cloud workspace using the
remote backend, we check the remote version is compatible with the local
one by default.

This commit fixes two bugs in this code:

- If using the "name" strategy for the remote backend, the list of
  destination workspaces is empty. This resulted in no version checking
  of the remote workspace, and we fell back to the string equality
  check.
- The user-specified CLI flag `-ignore-remote-version` was not being
  applied for the state migration version checking.

internal/command/meta_backend_migrate.go

@@ -77,15 +77,28 @@ func (m *Meta) backendMigrateState(opts *backendMigrateOpts) error {
 	// as we are migrating away and will not break a remote workspace.
 	m.ignoreRemoteBackendVersionConflict(opts.Source)
 
-	for _, workspace := range destinationWorkspaces {
+	// Disregard remote Terraform version if instructed to do so via CLI flag.
+	if m.ignoreRemoteVersion {
+		m.ignoreRemoteBackendVersionConflict(opts.Destination)
+	} else {
 		// Check the remote Terraform version for the state destination backend. If
 		// it's a Terraform Cloud remote backend, we want to ensure that we don't
 		// break the workspace by uploading an incompatible state file.
+		for _, workspace := range destinationWorkspaces {
 			diags := m.remoteBackendVersionCheck(opts.Destination, workspace)
 			if diags.HasErrors() {
 				return diags.Err()
 			}
 		}
+		// If there are no specified destination workspaces, perform a remote
+		// backend version check with the default workspace.
+		if len(destinationWorkspaces) == 0 {
+			diags := m.remoteBackendVersionCheck(opts.Destination, backend.DefaultStateName)
+			if diags.HasErrors() {
+				return diags.Err()
+			}
+		}
+	}
 
 	// Determine migration behavior based on whether the source/destination
 	// supports multi-state.