Persist normalization job failure reasons

[sherifnada]

Tell us about the problem you're trying to solve

If normalization fails, we currently only store the higher-level Temporal scheduling error in the Airbyte db, not the actual failure coming from Normalization (python error from the normalization code or DBT error coming from running normalization on the destination)

Describe the solution you’d like

We should use TRACE messaging to signal errors with attached failure reasons and use this to persists Normalization failure reasons correctly.

This then enables #14926 so we can track Normalization issues in Sentry

[sherifnada]

EOS update:

• DBT errors are generally one liners, so parsing them should be doable, need to get a clearer picture of how this would work. DBT v1 has JSON stacktraces but not all destinations do that. So we can't solely rely on DBT v1 log formats. Oracle is the only destination whose DBT v1 support is lagging.
• Decision: be okay with not parsing Oracle errors to Sentry. It will eventually get v1 support and be part of the Sentry incident reporting. So we'll build v1 log compatibility and accept not reporting Oracle errors for now.
• Instrumenting normalization worker to parse stdout and therefore parse TRACE messages now mostly happening locally

[Phlair]

Splitting this issue in two.
This issue now tracks the first part (PR: #14790)
This other issue tracks the second part (parsing and pushing to Sentry)