If CreateVarobjHandler::handle() calls Variable::setShowError(true),
Value="Error" is displayed for the Variable object forever because its
attribute showError() is never reset to false. A variable in a section
"Auto" of the Variables tool view retains its error status even across
debug sessions.

Once CreateVarobjHandler::handle() handles a result record without an
error, the past error(s) of the Variable object become obsolete and
unimportant. So reset Variable::showError() back to false in order to
display the relevant current value of the variable.

* extract rawUpdateField() to deduplicate a string literal;
* introduce a local raw pointer variable to eliminate a redundant weak
  pointer access in QPointer;
* remove a redundant check that the changelist is nonempty: if the
  changelist is empty, LldbVariable::handleRawUpdate() merely prints an
  inconsequential debug message.

A reference to MI::Value will be passed to the extracted function in the
next commit. Therefore, do not require a reference to a derived class
ResultRecord that is passed to the extracted function by its two callers
in this commit.

Optimize the extracted function and code that calls it slightly:
* deduplicate a string literal "value";
* introduce local raw pointer variables to eliminate redundant weak
  pointer accesses in QPointer.

Displaying the value of a variable in the previous format is confusing
and suggests that changing the format failed.

Return now useful information from LldbVariable::handleRawUpdate(). Make
handleRawUpdate() private because it is called only from
LldbVariable::formatChanged().

MIVariable::createChild() calls formatValue() on `this` rather than on
`var`, to which the returned value is assigned. But this distinction is
unimportant because the type of a child variable should be the same as
the type of its parent.

The added comments are based on my testing of kdevlldb and LLDB version
21.1.6 with 1) LLDB-MI version 0.1 and 2) latest LLDB-MI master version
lldb-tools/lldb-mi@7a907a6
The relevant behavior is the same in these two LLDB-MI versions.

An MI command -var-set-format takes the name of an existing variable
object as an argument. Consequently, neither GDB/MI nor LLDB-MI need a
thread and frame context for this command. However, GDB/MI (but not
LLDB-MI) always verifies that the thread and frame arguments are valid.
So if an ID of a nonexistent thread is accidentally passed to
-var-set-format, the GDB/MI command fails. For example:
    (gdb) 118-var-set-format --thread 2 --frame 0 var21 hexadecimal
    118^error,msg="Invalid thread id: 2"
Such a failure would desynchronize Variable::format() and the format of
the corresponding GDB variable object.

Do not pass the unused --thread and --frame options to -var-set-format
in order to eliminate the unnecessary risk of desynchronization, as well
as slightly improve performance by doing less work both in KDevelop and
in GDB/MI.

Introduce a new virtual helper function
MIVariable::handlerOfSetFormatCommand() in order to deduplicate
equivalent code in a member function formatChanged() of MIVariable and
its derived class LldbVariable.

The only consequential distinction eliminated by the deduplication is
that MIVariable casts to MIVariable* via dynamic_cast and LldbVariable -
via qobject_cast. This distinction was introduced almost certainly
unintentionally in 8dc24a5. The two
casts *should* produce identical results. However, kdevdebuggercommon is
a static library as a FIXME comment in debuggercommon/CMakeLists.txt
documents. Consequently, a qobject_cast to MIVariable* of a GdbVariable*
in kdevlldb or of a LldbVariable* in kdevgdb returns a null pointer, and
a dynamic_cast - a nonnull pointer. A fix of a crash reported in
Bug 509612 would prevent reuse of variables of incompatible types and
render the distinction unimportant. For now, an assertion that the
dynamic_cast returns a non-null pointer is less likely to fail, so keep
it.

Replace QStringLiteral(" %1 %2 ").arg(V, F) with
`V + QLatin1Char{' '} + F` in order to remove redundant spaces from the
command string and optimize.

Sending an MI command without a mandatory argument, i.e. the name of a
variable object, always fails. The replies to an MI command
"28-var-set-format  octal" of GDB/MI and LLDB-MI respectively:
28^error,msg="-var-set-format: Usage: NAME FORMAT."
28^error,msg="Command 'var-set-format'. Command Args. Validation failed. Mandatory args not found: format-spec. Not all arguments or options were recognised:  "

So soon as a MIVariable is attached and its varobj() becomes nonempty,
CreateVarobjHandler::handle() adds a -var-set-format command to
synchronize a format selected in the UI with the debugger (unless the
current format is Natural, which matches the debugger's default).