[Feature Request] Include error details on every errors thrown from Client API

[mjameswh]

Describe the solution you'd like

The concept of "error" at the grpc level is quite rigid and dry, consisting only of a message and an error code. To provide more context, the Temporal server sometime attaches an encoded error detail object as metadata on the error. We added support to decode these error details in #1147, which allows us to return specific, high level error classes to users in some specific cases (e.g. NamespaceNotFoundFailure).

It would not make sense to create a high level error classes for every error for which the server provides details, as the list of those errors is ever growing and many are very unlikely to ever happens in real life. Yet, users sometime need access to these error details to diagnose operational issues.

We should therefore always decode detailed error messages and make them available on the generic grpc errors, even if we don't make specific error classes for those details.

That however poses some challenges:

• Users wouldn't be able to use the instanceof operator to determine the exact type of error and which details are available, due to some oddities of how we do protobuf in the TS SDK;

• We'd likely want to see these details when an error is printed out, but they wouldn't be by default. Not even if doing JSON.stringify, unless the detailed properties are enumerable, which wouldn't be the case for objects coming from the protobuf library.

• Some error details may themselves contain other encoded protobuf objects, which needs to be decoded recursively. Can we dynamically determine which messages/properties contain recursively decodable messages, i.e. without implementing visitor logic for each of these error detail types?