Re-export rand_core

[newpavlov]

Closes #681

Also issue compilation errors if unstable functionality in the signature crate is enabled by toggling features introduced by optional dependencies. In theory it may break build for some people, but it would've happened eventually either way. Also I do not forward std to rand_core in this case since doing it correctly requires weak feature activation.

[tarcieri]

Also I do not forward std to rand_core in this case since doing it correctly requires weak feature activation.

The nice thing about doing this is it makes it possible to access OsRng without an additional crate dependency.

Perhaps as an alternative, we can add a getrandom feature which enables rand_core/getrandom instead?

[newpavlov]

We still will pull rand_core, even though the preview feature is not enabled. But on second though, forwarding std could be fine. Since if I am not missing something, rand_core does not become part of the crate's public API unless rand-preview is enabled. It would mean that we pull a dependency which will not be used in any way, but I guess it should be more or less fine.

BTW such complications is one of the reasons why I am not a huge fan of preview features and generally err on the side of caution with 1.0 releases.

[tarcieri]

I'll leave it up to you how you want to handle signature. If need be we can revisit it in another PR.

[newpavlov]

I think I will leave it as is then. Mostly because std is enabled by default in signature, so forwarding it would mean that users not dependent on rand-preview and who do care about using default-features = false will pull 2 dependencies (rand_core and getrandom) not used in any way by this crate. Yes, they are really common crates and quite small ones, but still it does not look great. Either way, we always can add such forwarding later.