Improve External Lookup fields to support key-value pairs.

Currently, External Lookup fields support JSON-based data sources, but only a single property can effectively be used/returned. This becomes limiting in real-world integrations where systems require a stored value that differs from the user-facing label.

Example:

[
  { "label": "Not Applicable", "value": "not_applicable" },
  { "label": "Brand New", "value": "brand_new" }
]

Today, we can only expose either the label or the value. In practice, this forces us to expose technical/internal values to end users so downstream systems can properly consume the data.

A common example is AEM Tags:

• label → human-readable value shown to users
• value → internal identifier/path required by AEM for storage and integrations

With the current limitation, users see implementation-specific values instead of clean UI labels because the native connector must send the correct stored value to AEM.

Suggested improvement:
Allow External Lookup fields to:

• display one property in the UI (e.g. label)
• store/send another property as the actual value (e.g. value)

This would align External Lookup behavior with standard enterprise patterns used across CMS, PIM, DAM, and commerce platforms, while significantly improving UX and integration flexibility.