Unckeck by default the children and links options for the copy action

In issue XWIKI-13162 the options "preserve children" and "update links" have been set to true by default for the copy UI as well, along with the rename.

For the Update links option the problem is even more complicated because of XWIKI-13625 (not displayed on screen to be changed by the user).

However, this issue is about unchecking these options by default for the case of the copy. Here is the logic for this:

• (assumption 1) in 80% of the cases, a copy of a document is done in order to create another document, a different one, using an existing document as a "model"
• (assumption 2) in many cases, the documents on a hierarchy do have some sort of content in them, besides having children (they're not only "containers" for their children), and a copy is done in order to copy this content
• (assumption 3) in 80% of the cases, the purpose of a rename of a document is a "move"

Based on these, it seems to me that the intention is different for the children in case of a "copy" than in the case of a "move":

• in the case of a move, the children would remain "orphan" if preserve children is unchecked, and nobody wants that
• in the case of copy, only the page on which the button "copy" was clicked will be copied if preserve children is unchecked, and everybody wants that

For the "update links" option, assumptions 1 and 2 above tell us that the copier's intention is to copy a content as a "base" and not a result, and will work on the page after copying it in order to obtain his desired result (thus, will be able to correct broken links if any). Doing some "stuff in the background" on copy could remove some of the control that the copier has on the copy he makes - if he has read the content of the page before copying it, it might arrive as a surprise that the content of the page after copy is not the same. This is particularily true in the case of an include macro, for example, which can change reference from relative to absolute upon copy (see the usecase in issue XWIKI-13625).