Fix for FORK branches with mixed outputs and unsupported field types

[ioanatia]

related: #121950

Fixes an issue when FORK branches have different outputs which contain unsupported fields.

When a FORK branch is missing an column X that is present in another branch, we add an EVAL X = null to make sure all branches have the same output. We also align the attributes with a KEEP on each FORK branch.

In the case where the indices we query have fields with mapping types that are not supported and the FORK branches have different outputs, we can get failures such as this:

FROM my-index
| FORK (DROP x) // x is missing
       (WHERE true) // x is UNSUPPORTED

{
  "error": {
    "root_cause": [
      {
        "type": "verification_exception",
        "reason": """Found 1 problem
line 3:12: EVAL does not support type [unsupported] as the return data type of expression [FROM my-index]"""
      }
    ],
    "type": "verification_exception",
    "reason": """Found 1 problem
line 3:12: EVAL does not support type [unsupported] as the return data type of expression [FROM my-index]"""
  },
  "status": 400
}

This is because we add a EVAL x = null to the first branch, with x having an UNSUPPORTED data type.

To fix this, we needed to make sure we don't break the current behaviour where if two branches have the same column name but with different types, we need to return a validation error.
For example, here we return a validation error and we need to preserve this behaviour:

FROM my-index
| FORK (WHERE true) // x is UNSUPPORTED 
        (stats x = COUNT(*)) // x is LONG

returns:

{
  "error": {
    "root_cause": [
      {
        "type": "verification_exception",
        "reason": """Found 1 problem
line 2:5: Column [x] has conflicting data types in FORK branches: [UNSUPPORTED] and [LONG]"""
      }
    ],
    "type": "verification_exception",
    "reason": """Found 1 problem
line 2:5: Column [x] has conflicting data types in FORK branches: [UNSUPPORTED] and [LONG]"""
  },
  "status": 400
}

[elasticsearchmachine]

Pinging @elastic/es-search-relevance (Team:Search Relevance)

[ChrisHegarty]

LGTM

[tteofili]

LGTM