Clarify or document exception guarantees and error handling

[ShaddyDC]

Description of the issue

I believe this project does not generally use exceptions. There exists the TfError error posting system, and that is what I've usually seen in my experiments to be used.
However, there exist issues like #2537, where an exception was reported. It has been fixed, but the explanation has left me a bit unsure if I can generally rely on the fact that no exceptions will be thrown when using non-plugin code.

I hope I have not missed this question discussed or documented somewhere else.

Desired solution

It would be great if there was a clarification on these details, maybe something like one of these:

1. OpenUSD does not use exceptions, and we guarantee that no exceptions will be thrown. Consumers can rely on this fact.
2. OpenUSD does not use exceptions, and we take a best-effort approach to minimising them when possible. We will probably fix reported exceptions, but we recommend against relying on this guarantee for critical applications.
3. OpenUSD uses some exceptions, and consumers are expected to handle this according to their requirements.

I assume that the code will still always need to be compiled with exception support because they'd need to be handled internally, even if they do not cross API boundaries.

Motivation

I assume this is also important for pure C++ projects, but we're using OpenUSD in a Rust application. To handle potential exceptions, we have to hand-craft our bindings using cxx. Otherwise they would result in an immediate panic, which does not fit our requirements.
If we knew that we could rely on an absence of exceptions, we could use autocxx instead to automatically generate all our bindings. This would significantly simplify the adoption of the project.

[jesschimein]

Filed as internal issue #USD-10474