[Security Solution] Extend the POST /upgrade/_review API endpoint's contract and functionality

[jpdjere]

Epics: https://github.com/elastic/security-team/issues/1974 (internal), #174168

Summary

• Refactor the diff model to implement the terms "solvable conflict" and "non-solvable conflict" in the code, as described in the Concrete field diff algorithms by type section of the RFC.
• Modify the ThreeWayDiff interface by replacing the has_conflict field with a conflict field which is a enum with the following possible values: NO | SOLVABLE | NON_SOLVABLE.
  • See Concrete diff algorithms tables to understand in which cases the API should respond with conflict: SOLVABLE and with conflict: NON_SOLVABLE
• Adjust the frontend diff components to this change.

Background

kibana/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md

Lines 1922 to 1930 in f5b93d5

	In general, for all types of fields, we will follow the heuristic:
	- if `target` === `base` && `current` !== `base`, we set merge proposal to be the current version, without a conflict
	- if `current` === `base` && `target` !== `base`, we set merge proposal to be the target version, without a conflict
	- if `base` !== `current` !== `target`: mark the diff as a conflict AND:
	- **if conflict is non-solvable**: use the `current` version as the merge proposal
	- **if conflict is solvable** use the generated merged version as the merge proposal (possible only in a few types, detailed below - see tables)
	Depending on the specific field or type of field we might want to apply a specific merging algorithm when conflicts arise. Let's propose different types.

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)