cruft now fails to apply, without providing conflict to manually resolve

Prior to cruft 1.4.0, if it was unable to cleanly apply a patch, it would produce a conflict that had to be manually resolved.

As an example:

For my own project template, I updated the cruft version to 2.2.0+ here: https://github.com/timothycrosley/cookiecutter-python/commit/4fe165a760a98a06d3fbef89aae3149767e489f3

If I do cruft update using 1.3.0, it fails but then leaves behind this conflict .orig for me to manually resolve:

diff --git a/pyproject.toml b/pyproject.toml
index 1902c9f..b3f1069 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -98,7 +98,14 @@ extra_css = ["art/stylesheets/extra.css"]
 name = "material"
 favicon = "art/logo.png"
 logo = "art/logo.png"
+<<<<<<<
 palette = {scheme = "isort"}
+=======
+pytest-mock = "^1.10"
+pep8-naming = "^0.8.2"
+portray = "^1.3.0"
+cruft = "^2.2"
+>>>>>>>

On cruft 2.2.0, it fails but then marks it as a success leaving no way for me to know what the intended update was:

Apply diff and update? (y, n, s, v) [y]: y
error: patch failed: README.md:7
error: repository lacks the necessary blob to fall back on 3-way merge.
error: README.md: patch does not apply
error: patch failed: pyproject.toml:23
error: repository lacks the necessary blob to fall back on 3-way merge.
error: pyproject.toml: patch does not apply

Good work! Project's cruft has been updated and is as clean as possible!

.orig files are messy, but it feels even worse to mark the project as updated when the update fully failed. I wonder if, we could update cruft to show the template diffs and request manually application of them in the case it cant apply them automatically:

Cruft was unable to automatically update pyproject.toml!

Here is what changed in that file:

-cruft = "^1.1"
+cruft = "^2.2"

Please manually update this file then enter Y to continue or N to cancel:

[samj1912]

I am looking into a more complex enhancement that will help with this but I wanted to get in a bug fix first 😃 See #49

[lsorber]

I can confirm that 2.3.0 addresses the issue, thanks!

That being said, I do think the output could be a little more friendly as to which files the developer should manually merge and how to go about that.