Perhaps we need to clarify the design of *_err_t types

[imlk0]

Currently, we define the error types in include/librats/err.h, but there are still some problems.

1. We have many similar error status, such as RATS_ERR_NONE, RATS_ATTESTER_ERR_NONE, RATS_VERIFIER_ERR_NONE. Currently we must be careful to avoid returning RATS_ATTESTER_ERR_NONE in functions of type rats_err_t. because caller usually just compares it with RATS_ERR_NONE. Same problem also exists when calling the rats_err_t function from a function of type rats_attester_err_t.
2. There seems to be confusion as to when to return a negative value for an error code. Although previous work has attempted to remove -, a few codes(1, 2)still use it.
3. The ERR_CODE_SUBCLASS is not clearly defined, and it seems to be a wrapper for some underlying error type. But it seems that subclass bits is erased in the definition of this macro.

I suggest a redesign of the error types, at least

1. We should clearly define the relationship between rats_err_t and the following rats_attester_err_t, rats_verifier_err_t. E.g., is rats_err_t is a superclass of the latter two?
2. We need to clarify when we should use rats_err_t, rats_attester_err_t, rats_verifier_err_t. For example, should some generic utility functions use rats_err_t, even though they may be called by functions of type rats_attester_err_t?
3. Need a better way to call each other between different types of functions.