[PoC] Use options resolver in BaseFieldDescription

[phansys]

Subject

I am targeting this branch, because this change breaks BC.

Changelog

### Added
- Leverage options resolver at `BaseFieldDescription`.

To do

• Fix tests;
• Decide how to deal with the invalid values (array) generated by BaseFieldDescription::mergeOptions().

Since BaseFieldDescription::mergeOptions() calls to array_merge_recursive(), the previously set options are being overridden as array:

If the input arrays have the same string keys, then the values for these keys are merged together into an array, and this is done recursively, so that if one of the values is an array itself, the function will merge it with a corresponding entry in another array too.

This, by instance, is causing "virtual_field" option to hold an array instead of a boolean at ListMapper::add().

[SonataCI]

Could you please rebase your PR and fix merge conflicts?

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[franmomu]

@phansys I think this could be great, just in case you want to|can continue working.

[phansys]

I agree @franmomu, I need to find enough time for this task.

[franmomu]

I'll leave it open, so it doesn't get lost.

[VincentLanglet]

There was some discussions about this:

• Keep only common option in FieldDescriptionOptions type #7103
• Fix phpstan field options #7101
• Manual merge #7099

Some options are global: type, template, role, ...
Some options are specific: inverse for boolean type, currency, route for url type, ...
Custom option could be possible for custom FieldDescription. I could indeed create a type Amount with an option show_currency: bool to display or not the currency.

So I'm not sure we can use an option resolver, since we should allow every possible options.
Or we have to say that non-generic options should be in a key templateOptions and this require a lot of BC.