Fix business logic errors in Condition API "saveCondition" method

Changes proposed:

Currently, when updating a condition it clones the condition, (ie instead of updating an existing row in the DB, it creates a new row in the DB that links back to the first row in the DB). If the the clinical status is not changed, it voids the existing row, but if the status is changed, it doesn’t void the existing row. We propose always voiding the existing row. Therefore, you have an audit trail of changes, but there’s always a single non-voided row containing the “most current” information about a condition.

Currently, when updating a condition, if you change the “clinical status”, the end date of the existing row is set to the onset state of the new version of the condition. Additionally, if the updated condition does not have an onset date, the date is set to today. We propose removing this. In general, the saveCondition method should not alter the onset and end dates in any way.

Making these changes should help us fix a lot of bugginess in the current Ref App Condition UI, this may break code others have written around Conditions. Specifically, we should alert the Bahmni Coalition of this change.

This would also make the Condition logic in OpenMRS Core divergence from the Condition functionality EMR-API (where the core functionality was originally harvested from). At minimum, we should flag the EMR-API code as deprecated.

See the following Talk posts:

https://talk.openmrs.org/t/conditon-list-proposed-changes-to-savecondition-api/29451

https://talk.openmrs.org/t/condition-list-implementation/29270

fyi burke ibacher mksd grace