Improve dataType selection for custom receipt

[standeren]

Description

Today there is unfortunately a requirement having a dataType for the custom receipt in the layout-sets file for a custom receipt. This is unfortunate because there is not always the case that an app-developer wants to connect any data to the custom receipt. Because of this we should make it easier for the app-developer to take an active choice to add a dataType only if they need it.

This is sort of a three-sided issue where we can consider different aspects:

1. Default connected dataType behind the scene To make it easier for the app-developer to understand that the data model connection is not required unless they are going to use specific data from a specific data model, we could connect the receipt to a datatype by default in the layout-sets-file and visualize the filed in the config panel as a "legg til datamodell" button that will change the connection. There is an issue with this tho: Until we are supporting multiple data models, the app developer will get the possibility to connect components to data fields from a model even though he/she have seemingly not connected a data model to the layoutset. So an alternative could be to show a default selected data type and include some information on what this connection implies and when you should consider changing it.

2. Information and handling of scenarios when the custom receipt ends up without a valid data type connected. This is a continuation of the point above. We will need some sort of information anyway on what it means to add/edit this data type. And especially what will be the consequence of deleting the connection or the data model. And should the consequence of it always be shown or only be shown if the connection is invalid?

3. What data types should be possible to select? ~Finally we need to consider what models to list as selectable. It is only valid to connect a data type that has been referred to by a previous task. So the most correct thing for Studio to do is to show only the used data models. But on the other side we cannot and should not assume what order app-developers develop in. Maybe they wish to build the custom receipt first before setting up the rest of the process? Then they would not be able to select any data model. And how should we validate if the config is still valid when other tasks are being changed? So maybe it is best to list all and simply inform them, as mentioned in point 2, that it is only valid to refer to a data model used in previous task~ EDIT: We decided to allow the user to "make mistakes" and list all available datamodels