Bump versions + Edition 2018 + Pcg64

[dhardy]

This combines a few things because we need a new minor version for several crates, hence:

• switch to Edition 2018 for these crates
• serde support is now available with either the serde or serde1 feature for most of these, excluding rand_isaac (which requires rand_core's serde1), though doc still says use serde1
• I added Pcg64 (been on my to-do list a while)

[vks]

What's the motivation for using the serde instead of the serde1 feature?

[vks]

Looks good otherwise. I don't understand the test failures on Linux beta and stable:

error[E0601]: `main` function not found in crate `monte_carlo`
  |
  = note: consider adding a `main` function to `examples/monte-carlo.rs`

error[E0601]: `main` function not found in crate `monty_hall`
  |
  = note: consider adding a `main` function to `examples/monty-hall.rs`

[dhardy]

Just because we can and some users may expect it to be just serde. Not a very good reason, which is why I didn't change the docs. 🤷‍♂️

I don't understand the failure either. Of course, we know those examples don't work with no_std due to use of thread_rng but why commit 01b1bf8 causes the command cargo test --no-default-features to fail is a head-scratcher.

[dhardy]

Note: I can fix the examples to work without std, but then all the doc-tests fail. On most no-std tests we already use the --tests flag to avoid this issue.

    #[cfg(feature = "std")]
    let mut rng = rand::thread_rng();
    #[cfg(not(feature = "std"))] // no support for thread_rng
    let mut rng = <rand::rngs::StdRng as rand::SeedableRng>::seed_from_u64(0);

[vks]

Just because we can and some users may expect it to be just serde. Not a very good reason, which is why I didn't change the docs. man_shrugging

I think this might be problematic if there is a serde2. Updating serde to be equivalent to serde2 would be a breaking change. Isn't that the motivation to have serde1 in the first place?

[dhardy]

Yes, and that's precisely why I didn't document it (due to the way optional deps show up as features, one should never consider an undocumented feature a stable part of the API IMO). But you may be right that it's better simply not to implement serde support without serde1.

[dhardy]

Reverted and pushed version bump for next RC