Rename action in WUI has no confirmation for clobbering another entry

[davidsarah]

If you rename a directory entry in the WUI, and the destination name already exists as a child of that directory, then the preexisting child will be clobbered without confirmation (even if it is an entry for a directory).

[This does not actually lose data: you can use the Back button to go to the earlier version of the directory page in the browser's cache, get the read cap for the file whose entry was clobbered, and add it back. A user who doesn't have a clear mental model of the distinction between files and directory entries, and the fact that pressing Back normally reads from cache, would probably not know that they can do this, though.]

There is an undocumented 'replace' parameter to the ?t=rename webapi operation, mentioned in ​http://allmydata.org/trac/tahoe/ticket/705#comment:16 ; replace=false will cause a failure if the destination entry already exists.

To close this ticket, add appropriate UI to the 'rename' page that controls whether the 'replace' parameter is true or false. Also document this parameter in source:docs/frontends/webapi.txt#L929