Exposing more details in 500-level `Error`s

From within a dropshot endpoint, we can craft a 500-level error that includes a message that's sent to the client; e.g., https://github.com/oxidecomputer/omicron/blob/faa8b8f7ed6eb0fcd6585dca862b028132a31282/wicketd/src/http_entrypoints.rs#L385-L392.

However, I don't think we can do the same with the omicron Error type; we have Error::InternalError { .. } and Error::ServiceUnavailable { .. }, but those only provide the internal message, which leaves the client with a generic external message. I imagine this is something we wouldn't use a lot (?), but it came up on https://github.com/oxidecomputer/omicron/pull/5686#discussion_r1588522084 where it would have been nice to give the operator more information about what they should do to recover.

Start with common/src/api/external/error.rs around lines 464-473, then compare the client-visible 500-level error handling in wicketd/src/http_entrypoints.rs around lines 385-392. Define the intended way for an omicron Error to expose additional recovery guidance while preserving its internal message, and verify that the resulting client response carries that detail.