Simplify error handling in failure mode or during finalization

Rationale

Error handling support in rcutils (and by extension, in every ROS 2 C library implementation or client code) falls short when it comes to error propagation when in failure mode or during finalization. As discussed in ros2/rmw_fastrtps#414 and ros2/rmw_cyclonedds#210, ensuring the initial error gets propagated, while no subsequent error goes unnoticed, clutters client code significantly.

Proposal

Introduce a mechanism for rcutils to distinguish between an error overwrite and a nested error that should be handled differently (e.g. logging to stderr directly). For that matter, have a thread local integer to track nested error handling scopes and a boolean in local storage to ensure a single error handling scope per function.

With an API like:

typedef struct rcutils_error_handling_scope_t {
    bool active;
} rcutils_error_handling_scope_t;

void rcutils_error_handling_scope_init(rcutils_error_handling_scope_t * scope);
void rcutils_error_handling_scope_enter(rcutils_error_handling_scope_t * scope);
void rcutils_error_handling_scope_leave(rcutils_error_handling_scope_t * scope);

a function may request rcutils_set_error_state to behave differently in between _enter and _leave calls, for its own code and the call chain that follows after it. In C++, RAII may be used to simplify API use even further.

Start by reviewing rcutils error handling and the linked rmw_fastrtps#414 and rmw_cyclonedds#210 discussions. Define the scope API and its behavior for nested errors, failure mode, and finalization; done means the initial error is preserved while subsequent errors are handled as specified.