Allow mapping "List (integer)" field type to `type: integer` and "List (float)" to `type: float`

Overview

Surfaced by @hoorooomoo at ✨ Support linking field types marked SUPPORTED from #3512433 to props in a `ContentTemplate` Active .

🐛 Find bug(s) that explain unmatched field type props Active added code to stop trying to match the 3 "list" field types (integer/float/string), with the following commentary:

    // The `list` field types allows each field instance to define its own set
    // of possible values. The probability of this exactly matching the explicit
    // inputs for a component is astronomical.
    // If we ever decide to allow this, then the `Choice` constraint must be
    // correctly specified on it. Otherwise, `::toDataTypeShapeRequirement()`
    // does not find any constraints and matches every such field instance
    // against every integer/float.
    'list_float' => ListFloatItem::class,
    'list_integer' => ListIntegerItem::class,
    'list_string' => ListStringItem::class,

That missed one key point though: mapping a predefined set of integers/floats (in such a field instance) to a type: integer/type: float prop works totally fine, with zero negative consequences.

(No such luck for "List (string)", because typically the values stored in there are "machine names", things such as "be_nl", "be_fr", "be_de" … — or "light", "dark" — or "red", "blue", "green". As such, they are clearly StringSemanticsConstraint::STRUCTURED. Which doesn't make sense to map to type: string, which are for StringSemanticsConstraint::PROSE. See commit 01088091 that introduced this — it predates the use of the d.o issue queue!)

Proposed resolution

Allow matching list_float and list_integer to type: number and type: integer, respectively.

User interface changes