Improve error handling for app extensions

[azrikahar]

Description

Closes ENG-56

Currently when an app extension is faulty or contains bugs, the error thrown will brick the app, thus requiring a browser refresh.

This PR aims to handle said errors more gracefully for app extensions such as panels, flows, interface and displays using the onErrorCaptured() lifecycle hook. It is then used inside a <v-error-boundary> component, similar to React's Error Boundaries and a Vue counterpart of error boundary.

For Module and Layout extensions, currently the added global error handler does prevent the app from breaking entirely anymore, but I've opted to not implement "low-level" error handler for them because they may incur more changes, to be more specific:

• Module: After this PR, module that has error will be a blank route, but we can go back to previous page since the global error handler prevents it from crashing.

  The blocker for lower level module error handler would be each module is wrapped by the RouterPass here:

  directus/app/src/modules/index.ts

  Lines 42 to 49 in 6793d9f

  	for (const module of registeredModules.value) {
  	router.addRoute({
  	name: module.id,
  	path: `/${module.id}`,
  	component: RouterPass,
  	children: module.routes,
  	});
  	}

  which is a functional component used in several other places:

  directus/app/src/utils/router-passthrough.ts

  Lines 1 to 8 in 6793d9f

  	import { h, Component } from 'vue';
  	import { RouterView } from 'vue-router';
  	const component: Component = () => h(RouterView);
  	component.displayName = 'router-passthrough';
  	export default component;

  so if we want to narrow down and capture module errors "earlier", we may need to have another router view wrapper specifically for modules.

• Layout: After this PR, layout that has error will just be empty (but nav, sidebar etc are all intact) and will not crash the app anymore.

  THe blocker for lower level layout error handler would be layouts are generally wrapped into LayoutWrapper in several places, so if we wish to capture layout specific errors, we may need to cover all layout wrapper usages in the app.

Panels

Before	After
Breaks the app, requires refresh	Shows an error icon and text, similar to when there's API errors when loading the panel(s)

Flows

Before	After
Breaks the app, requires refresh	Operation shows with error icon and text, similar to insights panels with errors

Interfaces

Before	After
Breaks the app, requires refresh	Shows a warning notice

Displays

• render-display

  Before	After
  Breaks the layout	Fallbacks to the raw value in text form

• render-template

  Before	After
  	Fallbacks to the raw value in text form

Type of Change

• Bugfix
• Improvement
• New Feature
• Refactor / codestyle updates
• Other, please describe:

Requirements Checklist

• New / updated tests are included
• All tests are passing locally
• Performed a self-review of the submitted code

If adding a new feature:

• Documentation was added/updated. PR:

[ConnorSimply]

LGTM, I didn't fully do extensive testing since it seemed like you did a lot with your gif's and the changes from Rijk above still needing to be decided/made.

[Nitwel]

Looking good, nice addition!

Resolved