[parity-util-mem] consider removing some features

[ordian]

This was brought up by @bkchr in paritytech/substrate#5658 (review):

Can we please fix this upstream?

The design of this crate seems somewhat broken.

Instead of our own crate depending on our own crates, it should be the other way around. primitive-types and all this ethereum stuff should depend on util-mem when a feature is activated.

I agree in general and don't know why it was done this way, but on the other hand it won't solve the problem here completely because there still be other dependencies we don't own present as features (like lru, parking_lot, etc.). Another thing to consider is to reduce the default feature set to std (but that's a breaking change).

cc @cheme

[cheme]

Yes the reversed dependency on the implementation was done at the time to avoid republishing the whole ecosystem (heapsize crate at the time was very troublesome to update). I don't remember very well but there was some other point that make it difficult, especially considering it was not sure if the crate will be use, maybe there was some external repo dependency at the time that did not exist now.
It can probably be done the right way for parity managed crate, I cannot say if it is worth the effort.

Putting only std in default feature seems like a good idea (default feature choice was dumbly chosen to simplify eth import since it was the only user)).