fix(go/adbc/driver/flightsql): Parsing column metadata in FlightSQL driver

[xborder]

• Fixes #2434
• Moved driver-agnostic metadata parsing out of shared_utils.go
• Each driver can now implement its own logic for handling XDBC_ fields using fields metadata
  • Snowflake and BigQuery drivers seem unaffected as they use separate implementations
• Relocated ToXdbcDataType function to shared_utils.go to resolve circular dependency issues
• Aligned implementation with documentation by:
  • Ensuring all documented XDBC_ fields are properly fetched
  • Removing undocumented fields (COMMENT, CHARACTER_MAXIMUM_LENGTH, XDBC_SCALE, XDBC_PRECISION)
    *COMMENT, CHARACTER_MAXIMUM_LENGTH seem to be snowflake specific even though it seems snowflake adbc driver has a separate implementation.
  • Couldn't find any documentation regarding XDBC_SCALE, XDBC_PRECISION
• Restored tests that verify proper metadata field population

[davidhcoe]

I will take a look.

[zeroshade]

why are we losing the ordinal positions for comparison?

[xborder]

Good question. The ordinal position is set based on the order in which the columns are processed unless there's a metadata key ORDINAL_POSITION.
While writing the test I realized that even tho the schema is built always in the same order, the deserialization would (sometimes) cause columns to be in different order. I couldn't exactly understand the issue (if it even is an issue).

To work around this, I ignored the ordinal position (flight doesn't even set ORDINAL_POSITION) and appended the name of the columns being processed to every fields

[zeroshade]

most likely the reason for that is because of the usage of a map. Golang maps do not have a guaranteed order and are in fact randomized when iterating. So you can't rely on the order of a map during iteration.