feat: replace f32,f64 with ordered_float

[ZENOTME]

simple solution for #116.

Why I introduce ordred_float diretly

The order: spec said we need to use -NaN < -Infinity < -value < -0 < 0 < value < Infinity < NaN.

I find that it's unapprpriate to implement this order in the custom float directly. If we implement -0 < 0 for the custom float, which means that CustomFloat(-0) < CustomFloat(0) will return true. Then what result of CustomFloat(-0) == CustomFloat(0) should return?:

1. true => it's confict with CustomFloat(-0) < CustomFloat(0)
2. flase => why -0 is unequal 0

I think this order is specific for the iceberg partition order. So this order rule should implement as a custom order trait or implement for AnyValue. E.g.

// implement as a custom order trait
impl PartitionOrder for OrderedF32 {
    ...
}

The hash: iceberg has hash specs for float value that: hashLong(doubleToLongBits(double(v))

Maybe we should do something extra here instead of store StructValue in hashmap directly.

I find that this hash is specific for the bucket transform. https://iceberg.apache.org/spec/#appendix-b-32-bit-hash-requirements:~:text=For%20hash%20function%20details%20by%20type%2C%20see%20Appendix%20B. So we also can implemment as specific hash trait rather than general hash trait. E.g.

impl BucketHash for OrderedF32 {
    // convert it to a 32bit hash
    fn hash() -> u32 {
        
    }
}

[liurenjie1024]

LGTM, in java we can define comparator/hasher to customized logic. In rust, the partition value doesn't have to be StructValue, but a newtype PartitionValue(StructValue), then we can define comparison and hash logic for partition.