add support for __int128, __int128_t, __uint128_t

[vogler]

Closes #41.
I left some TODOs where I wasn't sure.
Esp. if long long is already 128 bit on the machine, do we then want ikind ILongLong or IInt128?

(This machine-dependent ambiguity is a source of errors if one does not use CIL's functions but assumes e.g. long long to be of a certain size - might be better to let CIL just emit concrete int sizes like int32_t.)

[vogler]

Works as intended. The Parse error for fields starting with __ was just due to a typo in the typedef.

[MaskRay]

__int128_t and __uint128_t are also recognized as built-in types.

In particular, Nim generated C uses __uint128_t (e.g. with import tables) which I need to produce a self-contained C source file.

[vogler]

Mh, the lexer/parser is a bit hard to understand. I just wanted to return two tokens UNSIGNED INT128 for __uint128_t, but then how should the lexer's state be adjusted?
Alternative would be an extra token, but that would require some special handling outside of the type_spec rule, which is also messy.

cil/src/frontc/cparser.mly

Line 959 in 7a912dd

| type_spec decl_spec_list_opt_no_named { SpecType (fst $1) :: $2, snd $1 }

@MaskRay For now you can use the option cppflags to include a header file with typedefs for __int128_t and __uint128_t like done here: https://github.com/goblint/analyzer/pull/311/files

[vogler]

Added them as built-in named types on init and handled in cabs2cil. Should be fine to merge now.