[Notifications] Add more error context to error toasts

[rylnd]

Describe the feature:
As a kibana user, if my UI interactions generate an elasticsearch error, I want as much contextual information about the error as possible in order to diagnose and resolve my issue.

Describe a specific use case for the feature:
While #70404 added additional error information to our existing notifications service, that information is situational and not always present. I previously created an elasticsearch issue to discuss the behavior that I was seeing: EQL validation errors resulted in error toasts without any useful error information, despite this context being contained in the response.

While documentation around these errors and their topography is sparse, I'd like to propose the following change based on the behavior that I've observed:

1. Display top-level error.type and error.reason fields, if present
   • These fields appear to be an aggregation of the error.root_cause fields and so I think we can ignore error.root_cause; I've not seen anything to the contrary. However, I've not seen a situation where error.root_cause has more than one element so a quick verification from an elasticsearch team member would be great confirmed below that these top-level fields are meant to be presentational, and we should treat them accordingly.
2. Qualify the existing caused_by fields as such: a contributor to the top-level error
   • This is mainly to classify/disambiguate the relationship between the two errors that we'll now display. In the timezone example, the error was ultimately an x_content_parse_exception, but was caused more specifically by a zone_rules_exception

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[nik9000]

* These fields _appear_ to be an aggregation of the `error.root_cause` fields; I've not seen anything to the contrary. However, I've not seen a situation where `error.root_cause` has more than one element so a quick verification from an elasticsearch team member would be great.

They are a best guess for the root cause, yes. We unwrap things based on a heuristic until we hit an error that looks like it was "ours".

I think the ES contributors are in a better place to improve error messages and make sure that they stay fixed. The particularity of the way we handle errors in ES makes them kind of spooky-action-at-a-distance-y. So they are the kind of thing that if we rely on and particular error we should have assertions for it. I think working with some ES folks is probably going to be more fruitful than trying to reverse engineer how errors sometimes appear.

[rylnd]

Closing as per #81965 (comment)