[API user friendliness] StatusTuple can have canonical error code instead of an integer

Right now, StatusTuple accepts an 'int' as "error code". This because hard to enforce meaningful error code across bcc code base. And most of BCC code simply returns -1.

Blindly using -1 or inconsistent error code makes users difficult to react to error correctly.

For example, attach_uprobe() can return error when a probe was already attached before. Without a distinguished error code than -1, user code has no idea what to do with it. But normally user code want to just ignore this failure and move on.

I suggest to predefine a few canonical error code, where simple errors like duplicated operation can be reported as such.

This would means a tedious laborious changes to update all StatusTuple returning code, so far there seems at least 256 places. But that should be straightforward with a few lines of shell code.
$ grep 'return StatusTuple' third_party/bcc -R | wc -l
256

WDYT?

Start by reviewing StatusTuple and the return sites found by `grep 'return StatusTuple' third_party/bcc -R`, which reports 256 locations. The issue does not define the canonical error codes or the exact affected interfaces, so completion would require an agreed design followed by updating and validating those return paths.

Written by the indexing model from the issue text.