Define the UX for error boundaries around extension components

Goal
Leverage what was done in 4.11 and define the best UX for how we want to handle error boundaries around extension components.

Background
Adds error boundaries around extension mounting so that if a runtime render error is thrown, the component from a plugin cannot crash our application.

There are many ways code can crash and sometimes these crashes can be more than a call not made or an item not updated. Sometimes these crashes take the whole app with it – giving us the "white screen" situation.

React gives us something called Error Boundaries. These are special types of components that you can place anywhere in your React tree of components to only crash smaller parts of your app when things go awry. Even better, we can also put in fallback components to help more gracefully handle what happens when these crashes happen.

Now, add Dynamic Plugins into the mix, and all of a sudden we do not control all of our code running in OpenShift Console. Thus, what happens if a Dynamic Plugin brings in a component that crashes. We have a top-level Error Boundary, but can we do better? In comes this PR.

We wrap Error Boundaries around the usage of components brought in by plugins to help crash in smaller parts. Two types of error handling are done here.

If the component is large portion of the screen – like a route – we want our standard error crashing catch (this is our standard "Oh no, something went wrong!" pages.

If the component is a part of a larger piece, it could be a problem trying to render that whole page inline on a Dashboard Card (for instance) – so we have a new inline component

See Andrew's PR for 4.11: https://github.com/openshift/console/pull/11607#issuecomment-1158982917

It is expected that the user would be able to share this information with support to help come to a resolution.

Requirements
Consider creating an alert and work through some of the UX details around the 4.11 implementation - especially for the inline error use case as it can get tricky to understand that the error is identifying something that is unable to render and not related to content it is "sitting next to." Consider also working with the PF team to create a component for this.

Think through our error states today and consider what changes should be made to support these use cases:

• full page error — the “oh no, something went wrong” ones
• inline error — the red “Extension error view details” ones
• Nothing — an option if we want to just render nothing — but it may or may not work out well for some of the content as it is replacing content that may come with padding itself

Designs
To come