Control validation visibility and block forward-navigation automatically

### Description

It's becoming more and more complex trying to configure a form in such a way that the user experience is the best it can be, while also guarding against broken state. Our default settings are to not show any validation messages to users at all, until the user clicks a 'submit' button. At that point we show all the validations the user needs to fix in order to submit the form. However for many apps, they'll use dynamics (i.e. hiding or showing one component, or entire pages) based on user input. In that case they have to block the user from clicking 'next page' until a selection or valid input has been made, as that input decides the flow of the form going forward, and it doesn't make sense showing the rest of the form to the user until they've made that decision.

Historically, we've gone further and further trying to make this all configurable for app developers. In v4 it's possible to control not only when to display validation messages, but which validation types/masks are shown, for which pages (`current`, `currentAndPrevious` or `all`) and of course when. In Altinn/app-frontend-react#1862 I'm proposing a solution to make it configurable for the 'back to summary' button as well.

### What I _really_ want
In the future, I hope we can figure out a way to:

- Show validations at the right time, automatically. We already 'know' that we should delay showing required-validations as long as possible, and at the very least not show them while the user is typing. Other validations should possibly appear sooner, but at the same time it's annoying getting a 'Your email needs to contain the @ symbol' while you stopped to think a little. However, if you move focus outside that component, it might be time to show that validation message.
- Block the user from navigating to the next page if any future pages rely on them filling out something (or fixing a validation error) on the current page.
- Do similar things for repeating group rows (and sub-forms?). We should do more research into why some repeating groups have been configured not to close when there are validation errors.
- Show the _right_ validation messages in the `ErrorReport` on the bottom, and never show things unrelated to what the user is currently working on.
- Block navigation in other navigation components, such as `NavigationBar`. It should not be possible to skip forward in the form when there are major tracks the user needs to decide on first.
- Do better when informing the user why they can't be allowed to navigate. If you have multiple components on a page, but only one of them is actually required for a future track decision/dynamic behavior, it might be good enough to only let the user know they have to fill out that field?

### The balancing act
In essence, our job is to make forms accessible and easy to use for actual users, while at the same time giving app developers the powers and functionality they need to make complex forms - including dynamic behavior and tracks. The balancing act here is to try our best to give the user _freedom_ to fill out the form in their own time and order, while at the same time limit them _only when we really have to_ to make the form-filling more sequential.

Our default settings is now 'do whatever you want, in the order you want', but when giving full power to application developers, some tend to err on the opposite side of the scale by locking down the form so that you _have_ to fill out every field in the order presented in the form.

I think we should try to strike a balance where the user (and usability) is in focus most of the time, but only to the point where we don't break form logic. For the user it's useful to skip through the form in order to figure out if this is the form they should submit (and figure out what they need in terms of information in order to fill it out), but at the same time that's not really possible if the first component is a radio button group where they need to choose between 5 different options leading them through 5 entirely different routes when filling out.

### Additional Information
```[tasklist]
### Tasks
- [ ] https://altinn.slack.com/archives/C02EJ9HKQA3/p1708681672811379?thread_ts=1708603942.359629&cid=C02EJ9HKQA3
- [ ] Altinn/app-frontend-react#1862
- [ ] Altinn/app-frontend-react#504
- [ ] Altinn/app-frontend-react#1156
- [ ] Altinn/app-frontend-react#1772
- [ ] Altinn/app-frontend-react#308
- [ ] Altinn/app-frontend-react#1537
- [ ] Altinn/app-frontend-react#979
- [ ] Altinn/app-lib-dotnet#1157
```

### Also relevant
- https://github.com/Altinn/app-template-dotnet/issues/180

Start by reviewing the linked issues #1862, #504, #1156, #1772, #308, #1537, and #979, along with the referenced Slack discussion and app-lib-dotnet#1157. The issue presents a broad set of possible validation and navigation behaviors, so done requires an agreed, concrete scope before implementation can begin.

Written by the indexing model from the issue text.