What is the purpose of this PR / why it is needed?

The not operator has two variants. If used in front of
other operator it negates its evaluation.
If used in front of the binary expression, it negates
the entire expression. When not used adequately, it can
lead to issues, such as erroneous rule matching. To mitigate this misbehaviour, it is better to standardize the
usage of the not operator and if meant to solely negate
the result of the adjacent operator, use the lhs not operator rhs pattern.

What type of change does this PR introduce?

Uncomment one or more /kind <> lines:

/kind feature (non-breaking change which adds functionality)

/kind bug-fix (non-breaking change which fixes an issue)

/kind refactor (non-breaking change that restructures the code, while not changing the original functionality)

/kind breaking (fix or feature that would cause existing functionality to not work as expected

/kind cleanup

/kind improvement

/kind design

/kind documentation

/kind other (change that doesn't pertain to any of the above categories)

Any specific area of the project related to this PR?

Uncomment one or more /area <> lines:

/area instrumentation

/area telemetry

/area rule-engine

/area filters

/area yara

/area event

/area captures

/area alertsenders

/area outputs

/area rules

/area filaments

/area config

/area cli

/area tests

/area ci

/area build

/area docs

/area deps

/area other

Special notes for the reviewer

Does this PR introduce a user-facing change?