Replace uses of codet::move by codet::add(std::move(...)) [blocks: #2310]

[tautschnig]

This uses the new rvalue interface and enables removal of codet::move.

• Each commit message has a non-empty body, explaining why the change was made.
• n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[tautschnig]

This will require #3277 to be merged first.

[allredj]

🚫
This PR failed Diffblue compatibility checks (cbmc commit: a7cff47).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/90497423
Status will be re-evaluated on next push.
Please contact @peterschrammel, @thk123, or @allredj for support.

Common spurious failures:

• the cbmc commit has disappeared in the mean time (e.g. in a force-push)
• the author is not in the list of contributors (e.g. first-time contributors).

The incompatibility may have been introduced by an earlier PR. In that case merging this
PR should be avoided unless it fixes the current incompatibility.

[tautschnig]

@peterschrammel @thk123 @allredj I would guess that the TG failure is genuine with some use of .move. Assuming that is the case, could someone patch TG to use .add(std::move(...)) instead? This can be done immediately, there is no need for this PR to be merged for that to work.

[kroening]

In terms of performance, my suspicion is that the std::move provides no benefit -- i.e., just codet::add() would likely be fine.

[tautschnig]

In terms of performance, my suspicion is that the std::move provides no benefit -- i.e., just codet::add() would likely be fine.

I guess in most cases that is true, but #3067 had a discussion of possible copy-on-write breaks that could occur in some scenarios. I have admittedly not done a detailed review of the scenarios but rather went for a naive move -> add(std::move(...)) transformation.

[kroening]

I did look for these, and didn't spot any.

[tautschnig]

I'll add an independent review of all uses of std::move to my list. Unless pushed, I'd leave this PR as-is, but several of the std::move might go away in that subsequent review.