Derive Field value operator sets from Views data instead of a hand-maintained map

Problem/Motivation

FieldValue::getCategory() and operatorLabels() map field types to operator sets by hand. A field type the map does not know gets whatever the fallback guesses.

Meanwhile EntityViewsData already computes which filter handler applies to each field — StringFilter, NumericFilter, Date, BooleanOperator, InOperator, EntityReference — and field modules already override it for their own types. The module is maintaining a worse copy of data the site already has.

Proposed resolution

Look the field's filter handler up in views_data and derive the operator set from it, so a contrib field type shipping correct Views data gets correct segment operators with no change here. Keep an explicit fallback for fields with no Views data.

Remaining tasks

• Agree the handler → operator-set mapping and where it lives.
• Confirm behaviour for fields with no Views data.
• Check that a reference-hop path resolves to a Views data key on the hopped-to entity type, not the root.

User interface changes

Operator lists may change for some field types, in the direction of what the field module itself declares.

API changes

This promotes views from a guarded optional integration to a dependency of the base engine — or requires the hand-maintained map to survive as the views-off path. That trade-off is the substance of this issue and should be settled before any code is written.

Data model changes

None. Stored operators are unchanged; only which operators are offered can change.