CVL error response enhancements and panic recovery

[sachinholla]

1) If a REST request fails due to cvl error, all non-zero values from
CVLErrorInfo object will be encoded in the "error-info" field of
response data (RFC8040 section 7.1). The "error-info" value will be a
josn object with one field "cvl-error", whose value will be an object
containing data from CVLErrorInfo.

"error-info": {
    "cvl-error": {
        "error-code":   <CVLErrorInfo.Code>,
        "description":  <CVLErrorInfo.CVLErrDetails>,
        "message":      <CVLErrorInfo.Msg>,
        "table-name":   <CVLErrorInfo.TableName>,
        "table-keys":   <CVLErrorInfo.Keys>,
        "field-name":   <CVLErrorInfo.Field>,
        "field-value":  <CVLErrorInfo.Value>,
    }
}

ErrAppTag and ConstraintErrMsg are not included here since they will
be encoded in "error-app-tag" and "error-message" fields of the error
object.

The "error-info" may include other error details in future. Clients
should check for the presence of "cvl-error" field to identify CVL
error.

2) REST server recovers panicking request handlers to return an error
status 500 (internal server error) to the clients. Writes an error log
with "runtime error" prefix, which can be used to redirect such
messages to the device console (requires rsyslog config enhancements).
Previously, the panics would have abruptly closed client connection
without proper logs or messages.

3) Changed REST server to log all client data validation and translib
errors as warnings. They need not be errors in client app's context.
Errors returned by system APIs continue to get logged as error message.
This helps better monitoring and filtering of log messages.