Make PRNGs implement Clone instead of Copy

[nagisa]

Remove derivations of Copy trait from ChaChaRng, IsaacRng, Isaac64Rng
and StdRng and implement the Clone trait instead.

Copying is an implicit operation and the copy shares its internal state with
the original generator. This means the the two generators will yield exactly
the same sequence of values. This behaviour is considerably easy to trigger
by, for example, passing the generator by value to a function.

Clone trait, on the other hand, does no implicit copying. The user will only
be able to either move the generator or ask for a copy explicitly, via the
clone method.

The only downside to this patch is the fact that the implementations of
Clone::clone methods do not optimise down to a single memcpy, like the
derived Copy implementations did.

Although the Copy implementations of these random number generators are
suspected to not be used much, this is a [breaking-change].

Fixes #20170.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[thestinger]

Copy is used in places like Cell as a generic bound. If it's removed, useful functionality will be lost. I don't think opt-in copy should be used to remove Copy implementations based on very subjective coding style ideas. The same copying semantics will be there for clone but without fulfilling some generic bounds.

[cmr]

I agree with @thestinger here. It is somewhat of a footgun if you accidentally copy your RNG, but Copy has other very useful properties as a generic bound.

[nagisa]

It’s a fair point and, honestly, I can’t think of counter-argument to that…

[huonw]

I'm not sure how much sense it makes to use most RNGs with Cell, since they're often large so the overhead of Cell/the memcpys associated with Copy could easily be larger than that of RefCell. Not implementing Copy is certainly the most backward-compatible thing to do.

In any case, it would be good to have these structs implement Clone, a PR that adds that functionality (without removing Copy) would be accepted.

(It might be good to have some tests that check that let mut rng = ...; let mut rng2 = rng.clone(); give the same sequence.)

[aturon]

i likewise agree with @huonw that not implementing Copy is the most conservative choice, and in some cases may help avoid footguns; and on the other hand there are very few places where Copy bounds are required -- and Copy can always be reintroduced later if those use cases turn out to outweigh other concerns.