Spike: Investigate simplifying Segment diffing

[khvn26]

Currently, we store segment rules (including sub-rules) and conditions in separate tables, which makes validation / versioning code unnecessarily complex.

We need to investigate the following:

• Versioning requirements for the individual rules are currently unclear. We'd like to go over the current approach, informed by FE need to know about specific rule/condition versions, and re-evaluate whether it's more correct, effective, and user-friendly to harness simple text-based diffs instead.
• As a nice side effect, removal of SegmentCondition and SegmentRule models in favour of storing the whole segment data in a JSONField in the Segment model.

This spike should result in a PoC to give us an idea whether the change is feasible and/or beneficial in the long run.

Considerations:

• We'd like to have the data in Edge API / engine compatible format.
• This will require a data migration.

[emyller]

As an update, since this discussion we're already pursuing some of the goals described in this issue:

• We've dismissed adding version_of to rules and conditions (https://github.com/Flagsmith/flagsmith/issues/5770), and made PKs irrelevant in API communication when rewriting segment serializers (https://github.com/Flagsmith/flagsmith/issues/5769).
• On the frontend, there is relevant work in progress by @kyle-ssg: feat/segment-change-requests-simplified-diff.

We're prioritizing delivering segment change requests now, and will improve the data model towards a JSON approach later.

[emyller]

Thanks @kyle-ssg! I'll reopen this issue because I think we still need to simplify things on the data model side, as per the description:

As a nice side effect, removal of SegmentCondition and SegmentRule models in favour of storing the whole segment data in a JSONField in the Segment model.

We'll discuss it (cc @khvn26) and perhaps move onto a separate issue then.