Validate and warn about invalid application configuration

## Description
This need has been thought of and discussed a lot before, and while we would like to produce warnings/errors for invalid configuration in Altinn Studio, rapid feedback on changes is needed, so having these warnings in `app-frontend-react` as well might lead to a better developer experience for those working on their app locally. The code should preferably be written in a way that makes it possible to extract the code to also show warnings in Studio.

## Suggested validations
- Groups/repeating groups
- [x] ~~Group/component order. Groups should be defined first(?), and all children later in the layout. We should show a warning if a child is defined before the group.~~ No longer an issue in app-frontend
- [x] All children in the group should exist. Show a warning if a child component ID does not exist (or exists in another page/layout). Should of course also work when groups have a multiPage configuration.
- [X] Check that children are not re-used across multiple groups.
- [x] ~~Only allow two levels (regular repeating groups and nested repeating groups)~~ We theoretically support unlimited depth of repeating groups, although this will probably not look great in the UI.
- Component IDs
- [x] Warn about duplicate component IDs, even when IDs are duplicated across pages/layouts (hidden components will not differentiate on the page id, so duplicate component IDs across pages will have unintended consequences)
- [x] As long as `app-frontend-react` puts the repeating group indexes into the component ID, we should show warnings when component IDs could be misunderstood as having repeating group indexes (i.e. matching `-`)
- Data model bindings (moved to #1463)
- ~~[ ] Missing `dataModelBindings` for components where a binding is expected~~
- ~~[ ] `dataModelBindings` pointing to non-existing locations in the data model (use Levenshtein to find the correct one?)~~
- ~~[ ] `dataModelBindings` pointing to invalid types in the data model~~
- ~~[ ] I.e. `Input` supports strings and numbers (and with numeric data types, number formatting should be set)~~
- ~~[ ] Booleans are not supported/recommended (#205)~~
- ~~[ ] Repeating groups should have their `group` binding pointing to an array-type in the data model~~
- ~~[ ] Non-repeating groups should have all its children bound to properties of the same object in the data model(?)~~
- ~~[ ] Components inside groups must have their bindings contained within an object inside the array-type of the `group` binding~~
- Other component configuration
- [ ] Missing `textResourceBindings` where a binding is expected
- [ ] Properties for certain components that should be required and valid
- [ ] Checkbox group, radio, select etc needs options in some way (see #2579)
- [ ] Verify summary component reference
- [x] FileUpload\* components, when used inside repeating groups, should have a `list` data model binding
- [x] ~~`textResourceBindings` using keys that does not exist. As the keys are optional, we could potentially use a Levenshtein algorithm to warn when the binding is _almost_ equal to a known text resource ('did you mean ___?').~~ Should be covered by JsonSchema validation
- [ ] All the warnings for `dataModelBindings` should apply to variables in text resources
- [ ] All the warnings for `dataModelBindings` should apply to `dataModel` lookups in expressions
- [ ] Error if `maxFileSizeInMB` greater than `maxSize` set on the connected DataType in applicationmetadata.json, warning if smaller
- [ ] For components utilizing options, you should only define `source` OR `options` OR `optionsId` (and `secure` should only be set if using `optionsId`). If you set multiple of these, you depend on the order of the code that checks for these properties (which may be different in frontend/backend).
- Layout generic
- ~~[ ] Verify that all layout files validate according to the current layout JsonSchema~~ Moved to #1512
- ~~[ ] Warn if using older layout structure, not layout-sets~~ (not even possible anymore in v4+)
- XACML Policy
- [ ] Verify correct resources defined (app, org, task). Does it match metadata & BPMN
- [ ] Is the roles correct
- [ ] Does all rules define resource, action, and subject
- BPMN
- [ ] Flow between all tasks
- [ ] End and start
- [ ] Correct task types
- Text resources:
- [ ] Validate HTML and Markdown to ensure it is valid: https://github.com/Altinn/altinn-studio/issues/20378
- Other
- [ ] Include all the warnings/errors from expression validation (this is already implemented in `app-frontend-react`)
- [ ] Complain with an error if the (current) process Task (when using a data process type) does not have a data model
- [x] Check the version of nuget packages used, and warn if they're older than what we support
- [ ] Check the frontend version used, and warn if it's older than what we support
- [ ] Paths in presentation fields, and their data types:
- https://altinndevops.slack.com/archives/C045EB3JA9X/p1706020139996529

## Relevant issue(s)
- https://github.com/Altinn/app-lib-dotnet/issues/134
- https://github.com/Altinn/app-frontend-react/issues/743
- https://github.com/Altinn/altinn-studio/issues/1841
- https://github.com/Altinn/altinn-studio/issues/6503
- #2579
```[tasklist]
### Tasks
- [ ] https://github.com/Altinn/app-frontend-react/issues/1463
- [ ] https://github.com/Altinn/app-frontend-react/issues/1512
```

Start by reviewing the existing expression validation in app-frontend-react and the related issues #1463 and #1512. The unchecked checklist is broad, so first agree on a bounded validation scope; done means that selected configuration warnings or errors are implemented in the frontend.

Written by the indexing model from the issue text.