Improve error without required features for futures-test

[Nemo157]

fixes #1385

[Nemo157]

https://travis-ci.org/rust-lang-nursery/futures-rs/jobs/474096048#L531 shows the failure building the new crate.

Unfortunately the same thing that requires having an extra crate to test this causes the failure in https://travis-ci.org/rust-lang-nursery/futures-rs/jobs/474097015, I don't think it's possible to actually fix this properly with Cargo's current handling of features.

I'll try adding a std feature and an error message if this is not active so that users can fix it easily.

[Nemo157]

If someone attempts to use futures-test = { default-features = false } now they will get a useful error message:

→ cargo build --manifest-path futures-test/Cargo.toml --no-default-features
   Compiling futures-test-preview v0.3.0-alpha.11 (/Users/nemo157/sources/futures-rs/futures-test)
error: `futures-test` must have the `std` feature activated, this is a default-active feature
  --> futures-test/src/lib.rs:15:1
   |
15 | compile_error!("`futures-test` must have the `std` feature activated, this is a default-active feature");
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Thomasdezeeuw]

I don't think the std feature is required for future-test, only run_in_background needs std features from other crates I think.

[Nemo157]

For what it needs from other crates yes, but around a third of the rest of the APIs depend on Arc and a few are using Box::leak with ZSTs (probably possible to do soundly some other way, but I don’t know how). If anyone is actually using a no_std testing framework then I’d be happy to have the feature used here properly, I just don’t think it’s worth it at this point (after 80% implementing it, then reverting back to this).

[Thomasdezeeuw]

@Nemo157 Ok, then I'm happy to use the std feature by default, I don't have a no_std use case.

[cramertj]

Nice, this will be much better, thanks!