Don't hardcode 'value' key for textual field translation

Created a merge request that abstracts out the hardcoded 'value' logic.
If the FieldTextExtractor plugin returns an array of type ['value' => 'Some text'] in their extract() method, everything should keep working as before. But if the FieldTextExtractor plugin returns more dynamic properties, e.g. via the custom_field module, this would now work.
Example data in the extract() method for a "custom_field" FieldTextExtractor would then be:

['question' => 'Some question'. 'answer' => 'Some answer']

The changed logic applies both to the translation via the UI (Controller class) or via Drush. Ideally, both should be refactored to abstract out logic that is the same in both implementations, to allow less code duplication, but that seems out of scope for this issue.

Thanks for giving this some thought / review.

To summarize the discussion in Slack, it would be good to not hard code the skip list of possible column names to (delta, parent, etc.)
Possible solution to check special key of "_translatable_columns" (name discussable, could be "_translatable_fields" or simply "_columns")
in TextExtractor::extractTextMetadata():

        foreach ($fieldMeta as $meta) {
          $fieldParents = [$field_name];
          if (isset($meta['delta'])) {
            $fieldParents[] = $meta['delta'];
            unset($meta['delta']);
          }
          if (isset($meta['parents'])) {
            $fieldParents = array_merge($fieldParents, $meta['parents']);
          }
          $meta['parents'] = $fieldParents;
          if (!isset($meta['_columns'])) {
            $meta['_columns'] = ['value'];
          }

and then loop over "_columns" in AiTranslateController::translateSingleField()

Tested with updated patch for https://www.drupal.org/project/custom_field/issues/3529794 📌 Add support for AI submodule "ai_translate" FieldTextExtractor plugin Active and it all works perfectly!

Merged to 1.1.x and 1.2.x, thank you all!