Add workaround for misparsed casts

[schuessf]

Recently, we added some support for non-preprocessed files wrt. system includes. To do so, our implementations of ILibraryModel contain definitions of macros, functions and types defined in those includes, modeled in Boogie. However, we don't actually handle the includes, therefore they are unknown to the CDT parser. While this works fine for most of the cases, a cast with a type only defined in a system header, where the expression to be casted (such as (size_t) (x)) is actually parsed as a function call. Therefore, we may crash when handling this "function call", since the function name (i.e., the actual type name) is not known.

As a workaround, this PR identifies such "function calls" that are misparsed casts (i.e., function calls, where the "name" is a type in our library models that is in brackets) and handles them the same way as casts are usually handled. To do so, the code for handling casts was slightly refactored and simplified.

[maul-esel]

Thanks for looking into this issue!

However, I am quite hesitant about this workaround. It seems like a dangerous route to just accept that our parser yields nonsensical ASTs and then to retroactively try and reconstruct what the correct AST would be. I worry that this will be a challenge to maintain: who knows how many of these special cases we will start to add, whether they will behave consistently across dependency (parser) updates, what unintended side effects they might have on cases where the AST actually correctly represents the code, etc.

Especially now that we are not shortly before a major deadline that is hugely impacted by this bug, I think we should rather try to find a cleaner solution.