Linking: only rename file-local symbols

[tautschnig]

Rather than renaming whatever is to be added to an existing symbol table, always rename file-local symbols. This will make sure that we do not rename a symbol that a later translation unit wants to refer to.

Fixes: #7720

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[kroening]

I am a bit uneasy to rename proactively, but this is likely the easiest approach.

[tautschnig]

I am a bit uneasy to rename proactively, but this is likely the easiest approach.

Hmm, no, I think I managed to avoid this. When we have translation units A, B (seen in that order) with a file-local symbol X in A and a global-scoped symbol X in B we will now do:

1. We will have "X" in the symbol table after compiling and type-checking A.
2. When linking in B, we notice that there is a conflict on "X".
3. With the prior approach, we would have added B's X as X$link1. With the new approach, we now (that we are adding B) will instead rename the existing X to X$link1 and will add B's X as X.