Use const-generics to support arrays of all sizes

[noslaver]

As discussed in #1085, this PR uses min_const_generics to add support for random arrays of every size.
Currently this uses the existing nightly feature.
This currently updates the trait bounds on the implementation to require Default + Copy, which wasn't required previously, which is a regression compared to what is currently supported.
This can either be addressed by using unsafe code and MaybeUninit, or adding this new impl only for arrays larger than 32.

Open questions:

• Should this use a new feature flag?
• Any specific tests that should be added?
• Any documentation that needs to be updated?

[newpavlov]

@dhardy
Since the added code will soon work on stable, maybe we should introduce a separate feature (e.g. min_const_gen) instead of reusing the nightly one? Also personally I think it's fine to use MaybeUninit-based code to remove the T: Default + Copy bound.

[dhardy]

Once min-const-generics is stable we'll want a feature flag to opt-in to this behaviour (until bumping the MSRV), so we should add the feature now, yes.

Yes, we should just use MaybeUninit now then.

Any documentation that needs to be updated?

• Rng::gen
• rand::distributions::Standard
• Book: distributions
• Use minimal const generics for supporting arrays of all sizes #1085 mentions let bytes: [u8; 4096] = rand::random(); which might actually be a bad idea for two reasons:
  1. naively, this requires copying a 4kiB block out of the generator function (and wrapping functions) instead of merely passing a slice reference in (whether this is optimised may also depend on use of #[inline])
  2. the current implementation of gen for arrays uses rng.gen() for each element which is inefficient for values smaller than 32-bit; I think we can't fix this unless either we require [T]: Fill and T: Default (a regression) or we have specialisation (maybe min_specialization is enough; we'd also have to think about whether we want specialisation to enable value-breaking changes).

[dhardy]

I think this is mainly waiting on doc updates then?

[noslaver]

I think this is mainly waiting on doc updates then?

Yes sorry for the delay.

[vks]

Looks good to me!

[dhardy]

One more bit of doc and I think we're good to go.