Error reporting and automatic failover

### Background
We've had a few instances over the last few months where the frontend app includes errors that crash the whole app when starting.This happened because an update included code not supported in specific browsers, because a configuration option caused a react component to throw an error when rendering, and a missing null-check caused an error to be thrown in a saga.

When this happens, it's a hard show-stopper, and it usually leads us to scramble to either roll back fast or come up with a fix. It can also take some time before we're notified of problems like these, as it might happen in browsers/apps/situations we don't usually test. The last three times I've seen this it has been noticed right after an app-frontend update rolling out. I previously made the suggestion to [create automated automatic end-to-end tests](/Altinn/app-template-dotnet/issues/122) in order to test deployed apps automatically before rolling out a new version of frontend. That would indeed minimize this problem.

### Related issues
- https://github.com/Altinn/app-template-dotnet/issues/122 (somewhat solves the same problem, with lots more effort, but with some additional benefits)
- https://github.com/Altinn/app-lib-dotnet/issues/109 (could solve the same problem, roughly the same effort as this)

### Solution
This issue describes an alternative solution that would go a long way in mitigating issues like these. We already publish a [list of available versions](https://altinncdn.no/toolkits/altinn-app-frontend/index.json) on CDN, so we could implement an error handler that reports the error to us before trying to invoke a previous version of the frontend instead.

This requires us to implement the two parts of this solution:
- An error handler to catch all runtime errors happening in the app frontend, and report them in a way we'll notice (maybe by adding a new endpoint and reporting to app insights).
- Some code that recognizes that the app crashed before it could render anything, and attempts to load 1-3 previous versions of the app-frontend in order to get a working frontend.

### Considerations
- Make sure the code does not cause a near- infinite loop if an error occurs on every version of the frontend (each version loading the previous one). The code to try previous versions should probably short-circuit that code in previous versions.
- Make sure we catch all types of errors (as mentioned above, throws while rendering a react component, throws in a saga)

### Additional
Some commercially available error logging services:
- https://www.bugsnag.com/platforms/javascript
- https://trackjs.com/
- https://sentry.io/for/javascript/
- https://rollbar.com/platforms/javascript-error-tracking/
- https://catchjs.com/

Logging directly to Azure application insights:
- https://docs.microsoft.com/en-us/azure/azure-monitor/app/javascript

Start by reviewing the frontend startup and rendering flow, including React rendering and saga error paths, then inspect the CDN version list and the related issues. Done means runtime failures are reported, the app can safely try 1–3 previous frontend versions, and repeated failures cannot create an infinite fallback loop.

Written by the indexing model from the issue text.