Ability to generate a PDF without having a input form

Today a PDF is primarily generated using a PDF layout with summary components pointing back to other components used in a form layout. Some services owners, like DIBK, don't use input forms in Altinn but use the api's in the app to collect data from so called end user systems. In order for them to be able to create a PDF they would have to create an input for (which they don't need nor use), the create a PDF layout for that form. The latter is true as long as they can't use the automatically generated PDF layout.

Regardless if a service owner uses the input form or not, you would still have to create a PDF layout to control the layout of the PDF and what data to show. DIBK have a similar architecture as we do when it comes to how the PDF is generated, but the use a more low-level control of the generated HTML using Razor templates. While this works fine and gives complete control over the generated layout (at least in terms of html) it also leaves them with the work of ensuring that WCAG requirements are met.

**Possible solutions to consider**
1. Use a form layout - this would require that the automatically generated PDF is good enough to use. The form layout then acts as the PDF layout, but this would require the form to be hidden in order to avoid instances being created using the app frontend.
2. Extend the custom PDF layout we already have with a data model driven summary component(s) ie. don't point to existing components on a form layout, but rather point directly to the data and configure how they should be rendered (text, list, table etc.)

The risk of not meeting the PDF requirements on alt. 1 is a risk, but also the fact that you end up creating something that really isn't in use is not preferable. But it should be mentioned.

## Acceptance criteria
- [ ] Create a custom PDF layout with a high level of control on the output without using a form layout as the basis for the PDF
- [ ] The preferred language should be take from the users profile
- [ ] It should be possible to specify a language and hence override the users profile language

Start by locating the existing custom PDF layout flow and how it currently depends on form layouts, then trace how user-profile language is handled. Define the implementation against the acceptance criteria: independent high-control PDF layouts, profile-based language selection, and an explicit language override.

Written by the indexing model from the issue text.