Issues with Threading in Problem Reports

**The Problem:** DIDComm V2 `problem-reports` REQUIRE a `pthid` value, even though that may not always be possible to include.

[`problem-report` spec for reference](https://identity.foundation/didcomm-messaging/spec/#problem-codes)

Section of note:
> `pthid` - REQUIRED. The value is the thid of the thread in which the problem occurred. (Thus, the problem report begins a new child thread, of which the triggering context is the parent. The parent context can react immediately to the problem, or can suspend progress while troubleshooting occurs.)

Consider the following scenario:

In this scenario, since Bob cannot unpack Alice's message, he has no idea what that message's `thid` is. Therefore, any `problem-report` he constructs is out of spec.

This is just one scenario in which this issue occurs. The spec itself identifies the possibility of `problem-report`s being triggered by events other than receipt of problematic messages:
> `ack` - OPTIONAL. It SHOULD be included if the problem in question was triggered directly by a preceding message. (Contrast problems arising from a timeout or a user deciding to cancel a transaction, which can arise independent of a preceding message. In such cases, ack MAY still be used, but there is no strong recommendation.)

In this case, it's not that the appropriate `thid` is inaccessible to Bob; it simply does not exist. As such, any problem report generated in this manner is automatically out of spec.