FR: Represent more conflict state within the materialized file

[scott2000]

Is your feature request related to a problem? Please describe.
This was discussed in #3968, but it seems like a larger design change that we'll need to discuss further, so I'm creating a separate issue for it. @arxanas has a lot of good ideas in that issue. We currently have some state which is not represented in the conflict markers:

• Deleted files vs empty files
• Executable file vs regular file
• Rename/copy source and destination (not supported at all yet)
• Missing terminating newline (currently visible only as a comment, but it is restored from the current tree when parsing)
• Probably some other state as well that I'm forgetting

We may also want to consider:

• Support for conflicts between files of different types (e.g. regular file vs symlink vs Git submodule)
• Support for conflicts between files with different line endings (e.g. LF vs CRLF)
• Support for conflicts in binary files or Git LFS files

Describe the solution you'd like
It might be nice if this state could be materialized in the file and then parsed when snapshotting. This could be achieved with custom conflict markers like \\\\\\\ attribute to indicate special attributes, or included as a special section in existing conflict markers like [attributes...] at the end. See #3968 for more discussion.

Describe alternatives you've considered
We could decide that this state should not be materialized in the file, possibly to avoid the user accidentally discarding some of the state while resolving conflicts, or to make conflict markers simpler for external tools to handle.