Implement a chart field with custom chart data storage

Thanks @Murz for the time you have put into thinking about the charts module! I have renamed this issue because I do not think that the block implementation should be removed. There are three (at least) use cases that the charts module should cater to:

1) Views or API implementation for plotting data across internal entities or external datasources. For example, I have a site with numerous dashboards that uses Charts.

2) Field implementation, for when a chart would be closely associated with an entity type, such as a node, across a number of those entity types. For example, if one created a content type with a chart field, then one would expect that all of the nodes of that content type might have a chart that goes with them.

3) Block implementation, where a user wants a one-off chart that can be placed on any page, but doesn't necessarily have the data structure in the site to support a view as a block. This would also be useful for someone using the layout builder and settings tray.

So, we should make this issue about adding a field that creates a chart. Please note that the latest -dev has a sub-module called "charts_fields" and already contains one field to assist with scatter plots.

Implementing the charts field plugin in charts core would allow might help with the fix of #3060732: Move Charts Blocks to Charts Core by allowing user to add this new field type to a block type/bundle and use the new field widget to create charts blocks. I will check the current work in the chart fields and see if I can move this work forward.

I have been looking around to check which field storage we can use as an example and I came across the metatag contrib module and layout builder module in core. These two modules store complex data and I think we can use the same approach to come up with the chart field storage. So I think our next step would be:

1. Update the issue to reflect what our next move
2. Create the chart field type
3. Create the chart simple field widget which behave like the current chart block form
4. Create the chart field formatter

I think after this we can have follow up issues which can include:

• Create a "fancy" chart field widget
• Look into deprecating chart block and implement an upgrade path

This weekend I will start to work on creating the field type and the simple widget and hopefully have something for people to review by monday.

First pass on the implementation of the field type and field widget. Will be uploading today a following patch with the formatter and hopefully with with a configured block bundle which have the chart field to replace the current block config chart.

Here is another patch which contains the field type, widget and formatter. Next would be to:

1. create the block chart bundle and then add the chart field to it
2. create an upgrade path between the current block chart configuration to this one
3. clean up the block charts code
4. create a follow up issue to for data entry improvement

The patch applies and works for me. My priorities for the next steps would be:

4, 3, 1, 2. However, I think those can be moved into other issues. There are a few code nitpicks that I might want to make, so leaving as "Needs Review" for now, but I doubt any substantial changes are needed.

Thanks for your hard work on this, @nikathone!

Added a new patch with a few small fixes, mostly getting the attributes right in the template_preprocess_charts_item hook. I did see this (following) on line 33 of ChartConfigItemDefaultFormatter.php:

$elements[$delta] = $this->viewElement($item);

that PhpStorm claimed was unhandled.

@nikathone, how does this work for you?

Created https://www.drupal.org/project/charts/issues/3104993 and am making this issue fixed.