refactor: Rename event parameters to fields

[yanivagman]

1. Explain what the PR does

This PR renames the parameters field in event definitions to fields. This change reflects the evolving nature of Tracee, which now supports various event types beyond just syscalls.

The term "fields" more accurately describes the structured data within events, aligning with the concept of event schemas and the data section in the new event structure.

This renaming also avoids future confusion with the planned introduction of "event parameters," which will be configurable settings for modifying event behavior.

2. Explain how to test it

3. Other comments

[NDStrahilevitz]

What's the logical difference between the fields section and the data section? fields represents the metadata for the concrete data found in an event? If so, why not just align the names?

[yanivagman]

What's the logical difference between the fields section and the data section? fields represents the metadata for the concrete data found in an event? If so, why not just align the names?

I agree that clear terminology is crucial. Here's why I chose 'fields' for the event definition and 'data' for the output:

data in Output: This represents the actual event payload – the concrete values captured at runtime. It's the raw information associated with the event, like the arguments passed to a syscall or the contents of a network packet.

fields in Definition: This acts as the metadata or schema for the event. It defines the structure, types, and possible values within the data section.

While the complete term might be "data fields," using "data" for the output and "fields" for the definition provides contextual clarity and avoids redundancy.

[geyslan]

LGTM