Refactor system_library_symbolst to support languages beyond C

[peterschrammel]

This will be needed to distinguish internal and modelled functions for various input languages from actual user code in downstream applications, e.g. through the "isInternal" property in the JSON output.

[tautschnig]

Isn't all that it takes an additional check of the mode attribute of a symbolt?

[peterschrammel]

system_library_symbolst is misplaced in goto-programs because it is C-specific. We require similar system library information for each language that we support. Therefore there should be an interface in util, and the respective system_library_symbols implementations should be put into the language folders (the contents of the current system_library_symbols can go into ansi-c). This will also allow to access it transparently through languaget if necessary.

To solve the is_internal issue (#1272),

1. we could have an is_internal function that looks up the symbol attributes and system library symbols
2. or add an is_internal boolean to symbolt and assign it in the front-end, based on the system_library_symbols information, and whenever an auxiliary symbol is created.

[TGWDB]

Closing as suggested architectural change we're not progressing on. Please reopen if you believe this is erroneous.