Fix map key path handling in Delta schema extractors

[brishi19791]

Fixes #825

Both DeltaSchemaExtractor and DeltaKernelSchemaExtractor were passing MAP_VALUE_FIELD_NAME when recursing into a map key, so nested fields under a complex (struct/array/map) map key were qualified with <map>._one_field_value.<child> instead of <map>._one_field_key.<child>. This collides with the value-side fully-qualified paths and breaks any downstream lookup keyed off InternalField.parentPath (column stats, field resolution, etc.).

Changes

• DeltaSchemaExtractor: pass MAP_KEY_FIELD_NAME (instead of MAP_VALUE_FIELD_NAME) when building the key schema's parent path.
• DeltaKernelSchemaExtractor:
  • Same map-key path fix.
  • Guard the BinaryType branch with originalMetadata != null before reading XTABLE_LOGICAL_TYPE. Map/array recursion passes null metadata, so a binary nested inside a complex type previously NPE'd here.
  • Throw NotSupportedException on an unknown DataType instead of silently falling through (which would build an InternalSchema with a null dataType and "" name).
• Tests:
  • TestDeltaSchemaExtractor / TestDeltaKernelSchemaExtractor: add testMapWithStructKey, covering a map whose key is a 2-field struct (nullable + non-nullable) and whose value is also a struct, asserting both _one_field_key and _one_field_value nested parentPath propagation.
  • TestDeltaKernelSchemaExtractor: add testBinaryInComplexTypesDoesNotThrow, a regression for a BinaryType nested in MapType/ArrayType receiving null originalMetadata.

[vinishjail97]

Thanks for the contribution @brishi19791

[vinishjail97]

Changed the PR description to reflect the current state of the code.