Need server-side within-pod MOVE directory tree (for Trash)

This is proposal to add functionality to the server which would be much faster on the client than on the server.

In general it is not a good idea to move resources, as links to them break. One should leave them at the same URI and if necessary change who has access to then, change which other resources mention objects they hold and link to them, and so on.

An exception when the user wants to move something to the "Trash" directory as a precursor to deleting it. Imagine this being analogous to the way this works on Mac OS X for example. In this case, it will not be referenced in the trashcan, and links would only be referenced again if the files were resourced from the trash.

Example user story

• The user wants to delete files but in a way which is recoverable
• The user selects a original file or folder
• The user selects the operation "Move to Trash"
• The client uses discovery to find the URI of the user's trash folder, or creates one
• The client makes up a suitable destination URI within the trash folder
• The client writes metadata to the trashcan recording the original URI for that destination
• The client sends a request to the server to move the files from the existing URI to the trash URI
• The server moves the files and responds OK to the client
• The client refreshes or locally updates any record it has of the Container of the original which now has one fewer item

There is another user story for the users looking through the Trash folder, selecting the item, and restoring the data from the trash URI to the original URI.

Start by reviewing the proposed MOVE-to-Trash and restore user stories in this issue. Define the server-side behavior and request requirements for moving a directory tree within a pod, including what a successful response means; done should be a documented, agreed specification for the feature.