Allow depending on std without depending on backtrace

[daboross]

This is done through adding a new std2 feature which acts exactly like std, but without the dependency on backtrace.

This is a hack, but it should be an effective one until we can make 'std' itself not depend on backtrace in v0.2.

With this, someone can depend on failure = { version = "0.1", default-features = false, features = ["std2"] } to bring in std implementations without bringing in the dependency on backtrace.

---

I'm undecided as to whether this is a good idea. If failure 0.2.0 is soon to be created, this would be pretty pointless and create churn in the features and in crates depending on failure for no reason. If it's another half year away, this could be a good addition for allowing use of failure without backtrace backwards compatibly.

Fixes #127.

[mitsuhiko]

I wonder if we can merge it with a different name than std2 that we can carry around for longer. Something like thin_std or similar.

[daboross]

Once we're at 0.2 though, wouldn't thin_std always be equivalent to std?

Nothing in the std feature depends on backtrace so I don't see any reason std would depend on backtrace except for backwards compatibility. Even if both are kept as defaults in 0.2, I imagine they could be listed separate under default-features without any interdependence.

If you're thinking of keeping thin_std and std features around as exact equivalents for the sake of more backwards compatibility 0.1->0.2, I can get behind that. Just want to make sure we're on the same page.

[daboross]

Closing this as the failure library is now deprecated, and it is unlikely to be merged.