Do not raise conflict when a code in a patch was already added

[Konstantin Kharlamov <hi-angel@yandex.ru>]

So, steps-to-reproduce below rather full of trivia like setting up a
repo, but the TL;DR is:

Upon using `git rebase -i HEAD~1` and then `git add -p` to add part of a
"hunk" as one commit, and then using `git rebase --continue` so the
other part of hunk would be left in top commit; git raises a conflict.

It's spectacular, that content of one of inserted conflict markers is
empty, so all you have to do is to remove the markers, and use `git add`
on the file, and then `git rebase --continue`

Its a lot of unncessary actions, git could just figure that the code it
sees in the patch is already there, being a part of another commit.

Maybe git could issue a warning, or to question a user interactively 
(y/n); but raising a conflict IMO is unnecessary.

# Steps to reproduce

In empty dir execute:

	$ git init
	$ touch test
	Initialized empty Git repository in /tmp/test/.git/
	$ git add test
	$ git commit
	[master (root-commit) a7ce543] 1st commit
	 1 file changed, 2 insertions(+)
	 create mode 100644 test
	$ echo -e "foo\nbar" > test             # content you'll want to break
	$ git add -u && git commit
	[detached HEAD 9e28331] 2-nd commit
	 1 file changed, 2 insertions(+)
	$ git rebase -i --root
	Stopped at a7ce543...  1st commit
	You can amend the commit now, with

	  git commit --amend

	Once you are satisfied with your changes, run

	  git rebase --continue

Put "edit" for the 2-nd commit

	$ git reset HEAD^
	Unstaged changes after reset:
	M       test
	$ git add -p
	diff --git a/test b/test
	index e69de29..3bd1f0e 100644
	--- a/test
	+++ b/test
	@@ -0,0 +1,2 @@
	+foo
	+bar
	Stage this hunk [y,n,q,a,d,e,?]? e

	╭─constantine@constantine-N61Ja  /tmp/test ‹node-›  ‹› (e721fa3*)
	╰─$ git commit
	[detached HEAD 27b2f63] add foo
	 1 file changed, 1 insertion(+)
	╭─constantine@constantine-N61Ja  /tmp/test ‹node-›  ‹› (27b2f63*)
	╰─$ git rebase --continue
	test: needs update
	You must edit all merge conflicts and then
	mark them as resolved using git add

What happened is that it's obvious that the hunk was broken to multiple
commits, and git should figure that out, and not to raise a conflict.

Side note: for some reason in the test git didn't insert conflict
markers. It did in real-world usecase though, and there was simply no
content inside one of them.