Instantiate 'std' templates explicitly in the expression evaluator


Instantiate 'std' templates explicitly in the expression evaluator

This patch is a follow-up for D58125. It implements the manual instantiation and merging of 'std' templates like
std::vector and std::shared_ptr with information from the debug info AST. This (finally) allows using these classes
in the expression evaluator like every other class (i.e. things like vec.size() and shared_ptr debugging now works, yay!).

The main logic is the CxxModuleHandler which intercept the ASTImporter import process and replaces any std decls
by decls from the C++ module. The decls from the C++ module are "imported" by just deserializing them directly in
the expression evaluation context. This is mostly because we don't want to rely on the ASTImporter to correctly import
these declarations, but in the future we should also move to the ASTImporter for that.

This patch doesn't contain the automatic desugaring for result variables. This means that if you call for example
size of std::vector you maybe get some very verbose typedef'd type as the variable type, e.g.
std::vector<int, std::allocator<int>>::value_type.

This is not only unreadable, it also means that our ASTImporter has to import all these types and associated
decls into the persisent variable context. This currently usually leads to some assertion getting triggered
in Clang when the ASTImporter either makes a mistake during importing or our debug info AST is inconsitent.
The current workaround I use in the tests is to just cast the result to it's actual type (e.g. size_t or int) to prevent
the ASTImporter from having to handle all these complicated decls.

The automatic desugaring will be a future patch because I'm not happy yet with the current code for that and because
I anticipate that this will be a controversial patch.

Reviewers: aprantl, shafik, jingham, martong, serge-sans-paille

Reviewed By: martong

Subscribers: balazske, rnkovacs, mgorny, mgrang, abidh, jdoerfert, lldb-commits

Tags: #c_modules_in_lldb, #lldb

Differential Revision: https://reviews.llvm.org/D59537