feat!: data field decode types

[NDStrahilevitz]

1. Explain what the PR does

9e4e121 chore(integration): align to data decode types
14aa920 feat!(events): normalise data presentation types
d915bdd chore(bufferdecoder): readability refactors
d4892fa feat(events): streamline event data decoding types

14aa920 feat!(events): normalise data presentation types

(Almost) all event data type field names (post-decode) should now
conform to go type names. This will ensure a more consistent and simpler
format for event data.

d915bdd chore(bufferdecoder): readability refactors

Move some functions around, rename and improve documentation.

d4892fa feat(events): streamline event data decoding types

1. Reduce the type variance in data fields via hardcoding possible types
   decodable from the kernel.
2. Move data field decode types to the types/trace package
3. Make corresponding changes in eBPF and test code

2. Explain how to test it

1. Nothing should functionally change
2. Events will be emitted with new and simplified field types (BREAKING CHANGE)

3. Other comments

[geyslan]

How about reducing the size of readArgFromBuff() by replacing the switch/if branches with an already initialized array containing pointer functions for each type (ebpfMsgDecoder.Decode*)?

[NDStrahilevitz]

This is basically the planned next step. I plan to move the decoding mapping to a hash map similar to the processor and derive functions. In this way we, and plugin authors, can easily introduce new decoding strategies.
A useful example already exists in the code: we have two different submission formats for string arrays. Therefore we have a single "presentation type" with two "decoding strategies".

[NDStrahilevitz]

@geyslan I've opted not to make this step in this PR but rather in a followup so that we merge smaller chunks at a time as this is a large scale change.

[yanivagman]

Not sure what we are trying to achieve in this PR

[NDStrahilevitz]

Not sure what we are trying to achieve in this PR

The PR has two goals:

1. Reduce the type variance in data field declaration. We use concrete types instead, this is already achieved in the context of the below "decode types"
2. Decouple the single data type into a 1. decode strategy type (encoding the protocol between kernel and decoder, this should be a registerable method in the future) 2. presentation data type which encodes what kind of data the user will receive when reading the value (a float, an int, a string, some array, a timestamp, so on).

Currently only the first goal is achieved.