RocksDB Key Encoder for UnsafeRow that supports range scan for fixed size fields

To encode a row for range scan, we first project the orderingOrdinals from the oridinal UnsafeRow into another UnsafeRow; we then rewrite that new UnsafeRow's fields in BIG_ENDIAN to allow for scanning keys in sorted order using the byte-wise comparison method that RocksDB uses.

Then, for the rest of the fields, we project those into another UnsafeRow. We then effectively join these two UnsafeRows together, and finally take those bytes to get the resulting row.

We cannot support variable sized fields in the range scan because the UnsafeRow format stores variable sized fields as offset and length pointers to the actual values, thereby changing the required ordering.

Note that we also support "null" values being passed for these fixed size fields. We prepend a single byte to indicate whether the column value is null or not. We cannot change the nullability on the UnsafeRow itself as the expected ordering would change if non-first columns are marked as null. If the first col is null, those entries will appear last in the iterator. If non-first columns are null, ordering based on the previous columns will still be honored. For rows with null column values, ordering for subsequent columns will also be maintained within those set of rows. We use the same byte to also encode whether the value is negative or not. For negative float/double values, we flip all the bits to ensure the right lexicographical ordering. For the rationale around this, please check the link here: https://en.wikipedia.org/wiki/IEEE_754#Design_rationale