Show clearer information about create-as-update conflicts

When a submission is a create submission but is applied as an update, we flag it as a conflict because we want to alert a user look at it and verify the data. We also try to choose good information to show (which properties might have been reverted by applying the create later). We use the existing conflict panels as-is, but this means that there is some confusing and inconsistent messaging.

E.g. the author's view and central's view show the same thing and some text reads "This Submission update was applied to version 1 of this Entity, but it was created based on version 1." When the create-as-update causes a _soft_ conflict (i.e. no properties were changed), the conflict panels look extra confusing because they are brightly colored but don't really seem to show any problems. Maybe in this soft-conflict case, it should not be flagged?

https://staging.getodk.cloud/#/projects/103/entity-lists/colors/entities/8fd9ed10-f082-499a-b466-01957c6a2e7d


Eventually we would like to handle this situation differently. The important thing to alert the user about is that their data came in extremely delated and the create submission was missing for a bit, and they might have some bigger issue with their process.

We want to first wait and see how common a problem this is, though.

Start with the staging example and inspect the existing conflict panels and create-as-update behavior described in the issue. No files, tests, or entry points are named, and the issue does not define a concrete desired behavior; a decision on soft conflicts and clearer messaging is needed before implementation can be considered done.

Written by the indexing model from the issue text.