chore!: PartialOrd -> Ord bound for hashcollections

[dj8yfo]

This pr is part of #51 resolution.

It addresses the following comments of review:

Second comment is addressed by second commit: feat!: raise bound on keys in hashcollections PartialOrd -> Ord.
Code with f32 and f64 won't be affected by this breaking change, as f32 and f64 aren't Eq, so it's not possible to construct HashSet or HashMap with these types as keys in the first place (insert in both collections require Eq bound).

[frol]

It's a bit surprising that that's not the default. Probably makes sense to explain why we need this feature:

@matklad The reasoning for that de_strict_order was not enabled by default is that extra checks add performance hit (#162 (comment)), and if any of the dependencies use borsh with default features, there is no way to opt-out. Canonical deserialization does not seem like a crucial feature even for nearcore, so I would keep it off by default to trade correctness for performance.

@dj8yfo What do you think?

[matklad]

Sorry for being confusing, what I meant is:

this is surprising, so it must be documented clearly

not

this is surprising, so it must be changed

[dj8yfo]

Removed commit with making de_strict_order a default feature from history of this pr

[frol]

I cannot think of how we could handle non-Ord types in collections, so I believe it is a good move, but let's see how it turns out when we upgrade nearcore / near-sdk-rs.

[dj8yfo]

So far i've only noticed this example, affected by this PartialOrd -> Ord change, but in this case the types are either already Ord or Ord can be easily added to #[derive(...)]