Extend generated_name_override callback to variables

[justsmth]

Context

Modifying (typically "prefixing") library symbols is needed to avoid conflicts for applications linking to multiple version of the same library, or when linking to several similar-but-different libraries. For example due to their histories, OpenSSL, BoringSSL and AWS-LC share many symbols in common. To avoid problems for downstream applications that depend on more than one of these libraries, symbol prefixing is needed.

Problem

The recent addition of ParseCallbacks::generated_name_override allows for function names that were modified/prefixed during their build, to have the modifications undone so that the generated bindings expose the original/intended name of the function. This is working as intended. However, the problem is that this callback is currently limited to modifying only function names, whereas other symbols (i.e., "extern" variables) may likewise need their names modified/prefixed to avoid link conflicts.

Change

• This change updates ParseCallbacks::generated_name_override to accept a second parameter indicating the kind of item the name applies to (currently, either Function or Var).
• A CallbackItemKind enum was added to serve as the type for this second parameter.
• Tests have been updated to verify that the names of both function and variable can be updated by this callback.

[pvdrz]

@skmcgrail thanks for your contribution! I think it might be desirable to add more arguments to generated_name_override in the future and given that this is already a breaking change we could take an approach similar to this one #2355 and introduce a non-exhaustive struct (ItemInfo might be a good name?). What do you think?

[emilio]

Yeah, while we're changing the API, let's do as @pvdrz suggests to make sure that we can extend it easily in the future. Thanks!

[justsmth]

@skmcgrail thanks for your contribution! I think it might be desirable to add more arguments to generated_name_override in the future and given that this is already a breaking change we could take an approach similar to this one #2355 and introduce a non-exhaustive struct (ItemInfo might be a good name?). What do you think?

Great idea!