refactor(filter)!: Decommission ps.child.* filter fields

[rabbitstack]

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

ps.child.* fields have been a constant source of pain and confusion for both detection engineers and Fibratus maintainers. The whole point of having these fields was to designate the child process that was spawned as part of the CreateProcess event. So, the process state of the CreateProcess event would always reflect the parent, instead of the child being created.

This PR transitions from parent to child process state attribution in the CreateProcess event. The equivalent of ps.child.name is now the ps.name field, and the actual parent is yielded by respective ps.parent. fields. The consequence of this change is a small breaking change in detection rules, which are addressed as part of this same PR.

In general, not only do rules become more readable and intuitive, but also the code base is considerably reduced as it is no longer necessary to introduce the ps.child.* field for any new parameter or attribute that we expose through the rule language.

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 evasion

/area other

Special notes for the reviewer

---

Does this PR introduce a user-facing change?

---