Detect more ELF symbol kinds

[Amanieu]

This makes 2 changes to SymbolKind detection:

• STT_NOTYPE is detected as a label, since that's the default type given to a label in assembly code. This is also used for mapping symbols that are inserted by the assembler to indicate which addresses contain code or data.
• STT_GNU_IFUNC is detected as a function symbol.

[mstange]

I like this change, but just for reference I'll note that this change being published in a patch release caused some minor breakage for me, see mstange/samply@8541504.

[philipc]

Do you think it's enough for this sort of change to be treated as a breaking change? It absolves this crate of blame, but doesn't do much to make it easier for consumers to notice that it might be a problem.

My feeling is that the consumer should never rely on something continuing to be in the Unknown category, since this is the category that is most likely to change in future.

See also #214 (comment), where the issue is that we need to provide other means for the consumer to handle it so that it doesn't matter if the category changes.

[mstange]

Do you think it's enough for this sort of change to be treated as a breaking change? It absolves this crate of blame, but doesn't do much to make it easier for consumers to notice that it might be a problem.

I don't have strong feelings either way. What was causing confusion for me was that I fixed a bug on my machine, and then found that the fix was not working when I tried it on a different machine. This was because I didn't have Cargo.lock in the repo, and the two machines were using different versions of object. So treating this as a breaking change would have avoided that particular source of confusion. (I have now made it so that Cargo.lock is in the repo.)

My feeling is that the consumer should never rely on something continuing to be in the Unknown category, since this is the category that is most likely to change in future.

I think that is a reasonable position.