Support custom receipt without any data models

[olemartinorg]

Description

The custom receipt is loaded via layout sets today, and requires that a data type has been set. It then loads the full <FormProvider> which loads that data model. When using custom receipt together with autoDeleteOnProcessEnd: true we cannot show that custom receipt (there is a warning about this that falls back to the default receipt in ProcessWrapper) after the referenced data type has been deleted (because loading <FormProvider> would crash when the default data model is missing).

After #1484 is done, it might be easier to run FormProvider without a single/default data model, if we're able to load multiple data models on demand/when used. This should also mean that we can then add support for loading a custom receipt _without any default data model definedinlayout-sets.json` - as long as no components or text resources reference the data model that has been deleted.

Additional Information

• Support multiple data models in the same process task #1484
• https://altinn.slack.com/archives/C02EJ9HKQA3/p1711014605408439?thread_ts=1710928564.667399&cid=C02EJ9HKQA3
• autoDeleteOnProcessEnd set to true will not affect custom Receipt page #859

[bjosttveit]

Added this to milestone for v5. We should support not specifying a default data type for a layout-set in general. What complicates this is that we currently use the dataType to find out which layout-set is the current one (for some weird reason). If an app is slightly misconfigured today, things can still work due to some quirks in the logic that I don't quite remember the details of 😅 In a new major release we don't have to worry about breaking such edge-cases and we can safely remove this connection between dataTypes and layout-sets, and not require a default data type at all. This is indeed easier to do after #1484.