[iceberg] Support ARRAY, MAP, ROW type conversions in IcebergConversions

[weibangpeng]

Summary

• Added ARRAY, MAP, ROW type serialization and deserialization support to IcebergConversions
• Each element/field within complex types is prefixed with a 4-byte LE length to handle variable-length children correctly
• Null elements are represented with length -1

Test plan

• Added IcebergConversionsComplexTypeTest with 17 tests covering:
  • ARRAY: primitive types, strings, empty arrays, null elements, nested arrays, decimals, timestamps
  • MAP: int→string, empty maps, null values, array values
  • ROW: mixed field types, null fields, nested rows, fields with array and map
  • Mixed nesting: array of rows, map with array values, row with array and map fields
• All 67 existing IcebergConversions tests continue to pass (no regressions)
• IcebergCompatibilityTest (19 tests) continues to pass

Closes #3788

[JingsongLi]

This writes a Paimon-private encoding into Iceberg lower/upper bounds for nested types. Iceberg's binary single-value serialization only has implementations for primitive values (Iceberg Conversions throws for list/map/struct), so an Iceberg reader that sees these bounds will try to decode them as Iceberg metadata and fail or misinterpret them. If we cannot encode these values using Iceberg's standard format, we should omit lower/upper bounds for ARRAY/MAP/ROW instead of serializing a custom round-trip format here.

[weibangpeng]

Thanks for the review @JingsongLi! You're right that writing Paimon-private encoding into Iceberg bounds would break standard Iceberg readers.

I've revised the approach: instead of adding custom complex type conversions to IcebergConversions, I now skip lower/upper bounds for ARRAY, MAP, ROW, and MULTISET types in IcebergDataFileMeta.create(). This way, complex type fields simply won't have bounds in the manifest, and Iceberg readers will treat them as missing stats (which is already a valid case for the Iceberg spec).