`Engine` : `RemoteStashFolderData` could be refactored to `RemoteStashCopiedData`

[khsrali]

While changes for stashing are upcoming, specifically this PR #6746
It makes more sense to refactor RemoteStashFolderData to RemoteStashCopiedData and deprecate the other one.

The new class will also accommodate a new property, which is uuid of the original calcjob.
More description is given in this comment by @agoscinski .

[agoscinski]

We need to rediscuss this a bit because the class RemoteStashFolderData is not only specifying the stash mode but also offering a dedicated API for folders. In RemoteData we have the problem that this API is not in a separate class (like inRemoteStashData and RemoteStashFolderData) but all mixed in it. The reason was that RemoteData is documented to be used only for folders (even though this is also not consistent if one looks at the docstring). So we need to find a solution that is consistent with changes we would like to do in RemoteData.

Linking relevant issues and PRs for RemoteData #6807 #6804
Linking previous discussion on RemoteStashFolderData for reference #6746 (comment)
Ping @GeigerJ2

[agoscinski]

Discussed with @khsrali in case of the stashing the distinction between folder and file does not make sense since the targeted files/folders (source_list) are always put into a folder (target_base). The source_list can be a mix of files and folders. One can therefore find a solution to support single files with RemoteData (#1609) separately from the design of the RemoteStash* classes.