kimchi.exception: Properly Decode All Kinds of Exception Arguments

KimchiException provides the ability to translate each argument and the
error message. It decodes the translated message to unicode. It's also
smart and avoids decoding a unicode argument twice by a check to make
sure the to-be-decoded value is not unicode.

The problem is that when a KimchiException is initialized by an object
that can format itself to a unicode sting, for example,

try:
    ...
except OperationFailed as e:
    ...
    raise OperationFailed('KCHXXXX', {'err': e})

the variable "e" is not a unicode object so it passes the check
mentioned above, then it gets decoded twice and raises an encoding
exception.

This patch does not only rely on the type of the to-be-decoded object,
but also catches the encoding exeption. It firstly tries to call str(obj)
to get the ascii string of the obj, then decodes it to unicode. This is
valid for a normal string or any object that formats itself to a normal
string. If it fails, it tries to call unicode(obj) to get the unicode
string of the object. This is valid for objects that formats themselves
to a unicode string. In all, it handles various objects like following.

If obj is a unicode string, use it directly.
If obj is a normal string, decode it to a unicode string.
If obj can format itself to a normal string, format it and decode it to
unicode.
If obj can format itself to a unicode string, format it.

Another problem is that by the current design, KimchiException always
stores error message in unicode. This can cause encoding exception when
we call "str(KimchiExceptionObject)". This patch is not a total refactor
of the translation and encoding so it does not solve this problem. The
workaround is using KimchiExceptionObject.message instead of str it.

Notice: I'm following the Python str.encode and decode semantics in the
commit message.
"encode" means converting unicode sting to ascii/utf-8.
"decode" means converting ascii/utf-8 string to unicode.
"encoding" means the action of decode and encode in general.

v2
sosreport_generate() function in debugreport code encapsules an
OperationFailed in another OperationFailed and re-raise. This leads to
odd error message like follow:
 KCHDR0005E: Unable to generate debug report my-debugreport. Details:
   KCHDR0003E: Unable to create debug report my-debugreport. Details: -9.

The v2 patch excepts KimchiException and re-raise it directly to
produce a clean error message. For the rest vast kinds of exceptions,
it still translates it to OperationFailed and encapsules it. As a
result, all error recognized by Kimchi produces a clean error message
with specific KCHXXXX error code. And unknown error produces an error
message with KCHDR0005E error code following by the detailed exception.

Though the change in v2 solves a root cause and does not make use of the
KimchiException decoding improvements, the author still keeps the
decoding code to make KimchiException more robust to all kinds of
parameters in general.

Signed-off-by: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com>