Fix merging and renaming of inlines

[stilscher]

The renaming of inline functions was broken in that multiple functions with the same name were outputted in the merged CIL file. This also lead to difficulties with the incremental analysis in Goblint, because globals are expected to have a unique name (goblint/analyzer#836). Also, the merging of inline functions was not correct, because inline functions with different bodies would not be renamed and the wrong version of a function would be called.

This PR aims at fixing that. For this, a distinction is made which C Standard is used, i.e. whether the gnu89 or c99 inline semantics needs to be used. They differ in that for c99 inline functions have internal linkage by default, unless extern inline is used, whereas it is opposite for gnu89. They agree on static inline functions that can in both cases only be called from the same translation unit.

This is reflected in the following changes:

• matchVarinfo is only called for functions that can be called from other translation units. It assumes that the respective global has a unique name and aligns multiple occurrences (for example declarations) and creates a single varinfo for it. For inline functions that have internal linkage only, we instead call getNode.
• All internal inline functions are renamed to avoid duplicate names. When inline functions are successfully merged, this renaming is reverted.
• To distinguish between the different inline semantics, a c standard option is introduced. One can choose between c90, c99, c11 and gnu89inline, which represent the group of language standards and dialects close to it. The old inline semantics is used when set to c90 or gnu89inline while the newer one is used in the other cases. When using cilly, the option is set based on the gcc language options specified (default: c99). Otherwise the option can also be set through the configuration of Goblint (Option to set the C language standard for CIL in Goblint analyzer#905).

Closes #120

[sim642]

• All internal inline functions are renamed to avoid duplicate names. When inline functions are successfully merged, this renaming is reverted.

That means if only a single file containing inline functions is involved, so no merging happens at all, then it won't have its original name even though it's the easiest case where it should have?

[stilscher]

That means if only a single file containing inline functions is involved, so no merging happens at all, then it won't have its original name even though it's the easiest case where it should have?

No, that is not the case. Renaming here means, it finds a new name (e.g. add__0) only if another function with the same name was already encountered. Otherwise the original name (e.g. add) is just kept.

[michael-schwarz]

Apart from my small comments above, this looks good to me!

[michael-schwarz]

LGTM!