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

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 #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 `(*).` or `->` 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 `` -> `*` -> `(*).`. 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 #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 #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).