C.65 Self-move - require only valid but unspecified

[bgloyer]

Cleaned up C.65: Make move assignment safe for self-assignment based on the discussions in #1892 #1649 #1606.

[cubbimew]

This seems more radical than #1606:

• current C.65 requires that self-move is a no-op and insists on not doing the STL thing (self-destructive self-move)
• #1606 points out that it is incompatible with rule of zero for classes that have members of STL types but can be worked around with copy/swap,
• this PR flips C.65 around to do the STL thing and not require no-op

As I recall, response to #1606 stalled because there was a draft paper on that topic.

[bgloyer]

Can we use 'valid-but-uspecified' until it is offically settled? I don't think it is practical to have the rule stronger than what the stl types do. Any type with an stl memeber that uses the rule of zero or = default would violate this rule. Or maybe have two rules, one that says 'valid-but-unspecified' and a stronger one for 'nop'? Then developers could choose which is appropriate for them? Setting 'valid-but-uspecified' as a minimum is important so that a type will work with swap.

[MikeGitb]

I like the Idea to stick with the stl behavior for now, but would love to see more data about the need for stronger rules. Has anyone had anekdotal or regular encounters with a self-move outside of self swap (where you don't care about the value)? What were the consequences for this?

[hsutter]

Editors call: This would invert the guidance and we agree with the current guidance -- self-move should be a no-op.