Some `Debug` and `Display` impls are hidden behind the `std` feature

[aleasims]

I found out that a lot of Debug and Display impls are gated by std feature (e.g. here, here, and in many other different places). I'm wondering was it done on purpose or just by a mistake?

Those traits are useful in no_std crates. For example, I'm using your library in no_std environment and I'm not able to do things like:

fn error_to_string<T, E>(error: TrieError<T, E>) -> String {
    error.to_string()
}

I'd appreciate any comment on that.

Also I'm ready to help cleaning up the no_std support in all the crates to get rid of "hacky" solutions with rstd and to make it look more "sound". Does it sound reasonable to you?

[aleasims]

Here is an example PR of what could be done to improve no_std compatibility:

• Make hash-db always a no_std library #229

[cheme]

It was likely a deliberate choice at the time. Crates defined as no_std would have no chance to accidently include this kind of bytecode, maybe at the time confidence with the compiler triming properly unused code was low too.
no_std was (and maybe still is) a shorthand to runtime target (so targeting minimal build size).
Does it still make sense, I am not too sure, accidentally including the debug/display code in runtime builds is quite bad, should it realy on no_std declaration, maybe not (ideally on shall identify the runtime target somehow, long time I did not interact with the project so I am not sure if no_std is still implying runtime target)_