Supporting moving files from one project to another [INS-3865]

[yaoweiprc]

Support moving files(collections/documents/mocks/envs) from one project to another.
Due to the cloud synchronization mechanism, the move operation is implemented by first copying the file to new project and then deleting it in previous project. This may lead to some unexpected results:
1. Since the deleted files will not be automatically removed from the clients of other collaborators within the same organization, when User A moves a file from Project X to Project Y, User B will have two identical files in both Project X and Project Y.
2. The IDs of the files and their subfiles will change after the move, so if a mock file is moved, the mock URL will change, and the old mock URL will no longer be available.

[CurryYangxx]

Do we need to add some description text to prompt the user that the mock server URL will change after move to another project?

[CurryYangxx]

Just leave a comment here and need a discussion:
@gatzjames We want to move db calls out of UI, but it seems unnecessary to create a new loader in this situation. The DB query will invoke the main process logic through IPC.

[yaoweiprc]

We initially intended to implement the feature to move files to another project, but we discovered that due to issues with cloud synchronization, true file movement couldn't be achieved. Therefore, we have enhanced the existing copy feature, allowing users to now choose the organization and project to which the files will be copied.

Why we can't implement real move:
I had considered implementing a real move operation that keeps the file IDs unchanged, but it introduces several problems in cloud sync:
If we directly change the parentId of the workspace from the old project to the new project, the server currently does not support synchronizing this behavior to other collaborators' clients. Even if the server supports this mechanism, we automatically executing the move operation for users when they receive the move message. It would not work for users using an older version of the client, as they wouldn't be able to achieve this synchronization.
I also tried simply copying the workspace and pointing the parentId of all sub-files of the original workspace to the new workspace, and then deleting the old workspace. However, this method also fails to synchronize on the collaborators' clients because deleting the workspace does not result in the workspace being removed on the collaborators' clients (We do not delete local files for user when the same one is deleted remotely). When the new workspace is synchronized to the collaborators' clients, the synchronization fails due to non-unique IDs of the sub-files.