Hack for conda includes

[ubaidsk]

One needs to add their conda include paths below which is a hack.

lc/src/lc/clang_ast_to_asr.h

Lines 1855 to 1870 in 9c855f9

	std::vector<std::string> include_paths = {
	"include/c++/v1",
	"include/stddef.h",
	"include/__stddef_max_align_t.h",
	"usr/include",
	"mambaforge/envs",
	"lib/gcc",
	"lib/clang",
	"micromamba-root/envs",
	"micromamba/envs"
	};
	for( std::string& path: include_paths ) {
	if( file_path.find(path) != std::string::npos ) {
	return false;
	}
	}

[certik]

We need to fix this in a robust way. Let's see what we need:

• We need to recognize the C++ standard library and not parse its Clang AST nodes at all, instead recognize what is included (say std::out) and handle it directly
• We need to recognize user include files and treat them in a special way: parse those separately into an ASR module, and then just include such a module
• We need to recognize third-party libraries like xtensor, not parse it and treat it directly

How to do that? Here are some ideas:

• We can require user include names to not clash with C++ standard library nor with any third-party library that we support directly. So iostream will always mean C++ standard library and never a user include. Then we can simply match for the name of the include at the end of the path and be done with it. This will be conda independent and user installation independent. But it has a downside that user include file must not clash, which might be ok for the main include files, but I suspect even a lot of the standard library (and xtensor) recursive includes might have some more "common" names that might clash.
• We can require a compiler flag (similar to -I) to specify the C++ standard library path, and another or the same flag to also specify xtensor location. And/or a special flag to specify user include locations, for example we could require strict -I flags for all user includes, and if the Clang AST header file is specified explcitly using -I, then it is user header file, otherwise it is "built-in". The problem is what to do if we use a conda environment that has both xtensor and user include files with the same prefix.
• We can specify conda include dir explicitly, or support something like --include-conda.