Issues with expressions across `evaluate` and `variables` requests

[jreineckearm]

A collection of issues found with using evaluate and variables requests. These need to be addressed bit by bit, fixes need to come with proper test coverage. First tests can found in #459

Impact of issues

Mostly impacting evaluateName property of variables returned in the variables request. evaluateName expected to be used in:

• Context menus ("send expression abc to debug view xyz"). For example when sending an expression to the Memory Inspector
• Views that interrogate for known global symbols. And where returned evaluateName is used for new evaluateRequests. I believe this is the use case where we stumbled over Evaluation of variables to support RTOS Views extension #400

Known issues

• More an internal problem: expression evaluator doesn't make use of parent object types when forming the parent part of child evaluateName. May be required for pointer de-referencing.

• Pointer de-referencing uses normal struct member access notation in evaluateName. This works due to how GDB works, but may fail if analyzed in custom views. Use either (*<ptr>).<child> or <ptr>-><child> notation. The first may be easier to apply since more scalable.

  • Note: It looks like GDB doesn't bother with a "de-reference" child, like in a chain <ptr> -> *<ptr> -> (*<ptr>).<child>. This slightly complicates things, but should still be manageable.
  • Note: It looks like this is only a problem when getting the direct child variables of an evaluate result. When you go deeper, it seems to correctly resolve to ->. Possibly due to the two locations where we construct these: handleVariableRequestObject() and handleVariableRequestFrame()?

• Typecasts are not embraced by parenthesis. I believe this was supposed to be fixed with Remove parenthesis cleanup & extra getFullPathExpression() calls #322 . Needs review now that things have changed/are changing in this area. Note, I believe other debug tools I used go a more brute force approach of adding parenthesis everywhere. Which is what the parenthesis part of Remove parenthesis cleanup & extra getFullPathExpression() calls #322 does.

• We only distinguish between local and register types on DAP level. Also should add global, but I don't know how much GDB helps with finding this from an expression.

I don't see any of this massively breaking debug features natively built into Theia/VS Code.
Also, things may just work if the expressions are passed back as they are to the CDT GDB Adapter. But they may be confusing for users as not all of them are valid/expected C/C++ expressions (pointer notation, expected precedence of tokenized expression).