refactor(types): Do not derive e.g. Ord on ScalarImpl

[jon-chuang]

    Turns out the actual issue is due to `#[derive(PartialEq)]` on `ScalarImpl`. Its actually quite a bad thing to have as there should not be any meaningful notion of PartialEq on ScalarImpl. 

Originally posted by @jon-chuang in #5771 (comment)

e.g. Int64() > Int32() is always true due to enum position rather than our actual comparison.

This doesn't seem like behaviour we would want.

If we want, we can define manually semantically correct PartialEq on ScalarImpl that agrees with our expression framework.

[BugenZhao]

Agree. I guess what you mean is not to derive Ord. #4272 (comment)

BTW, could we borrow the idea of PartialOrd to return None when comparing different scalar types?

[jon-chuang]

I guess what you mean is not to derive Ord. #4272 (comment)

Yes

BTW, could we borrow the idea of PartialOrd to return None when comparing different scalar types?

Indeed. Not sure if it would be useful, but that seems the most broad statement that is still correct.

[BugenZhao]

Actually, I think there should be rare cases to directly compare two datums in production: every comparison should be done by expressions (expect for the current implementation of dynamic filter). 🤔 So to avoid misusing it, maybe we can directly panic when comparing different scalar types.