Allow @FieldType to customize views data

Rebased branches, and made a new MR for 9.5.x.

Not had time to consider the architectural questions raised by Berdir :(

I wonder if plugin decoration would be a way to do this: #2958184: Allow decoration of plugins → .

Or we just specify a handler class name?

Amazing! Hiding patches iFo the MR.

I've just realised this is closely linked to hook_field_views_data_views_data_alter()

The docs for that say:

> The Views module's implementation of hook_views_data_alter() invokes this for each field storage, in the module that defines the field type. It is not invoked in other modules.

So it's basically: the module defining the field type gets to say something about Views data. That hook is still needed, because it allows field type providers to do things like reverse entity references.

But as a follow-up we could move that hook to the new handler classes that this issue will introduce.

I'm removing commit e7790601 because it's making lots of unrelated changes, which is making the branch harder to rebase.

Rebased to 11.x and made a new branch.

Can we clean up the unused MRs?
Also does this have to be annotations still?

If the approach with a new plugin type is used, then this definitely needs an attribute, and probably should replace the annotation.

Though I think @berdir suggested in #102/MR review that tagged services might be a better way to go than plugins?

This is going to be a pretty painful rebase now that views.views.inc is gone, but yes, since it is now in a service, I think it would make a lot of sense to make that essentially a tagged service and then we can just inject the handlers into that. I have this open and plan to see if I can make that work.