BTreeMap and potentially other FromIter codec does not have strict one-to-one correspondance

I'm not sure whether this would be an issue for SCALE, but for SSZ and RLP, strict one-to-one correspondence is usually required.

Current FromIter codecs (like the implementation for BTreeMap) does not enforce ordering. This means that multiple encodings are representing the same value. This will make code like below unsafe (consider if the definition of Extrinsic has an item of type BTreeMap):

let extrinsic = Extrinsic::decode(&input);
// do something.
validate_extrinsic_against_signature(blake2(extrinsic.encode()), signature);

I'm not sure we need to fix this, and if we need to fix this, how do we deal with backward compatibility (we need to make sure no one ever encountered a many-to-one in a production blockchain outside of runtime). If we decide to leave this behavior as it is, I suggest we put some sort of warnings in the implementations of those FromIter codecs, indicating that code snippets like above may be unsafe.

No file or test is named. Start by auditing the FromIter codecs, especially BTreeMap, to determine whether unordered input creates multiple encodings. Resolve whether canonical ordering must be enforced or warnings are sufficient, while considering backward compatibility.