Failing to bzr resolve multiple conflicts bzr: ERROR: Tree transform is malformed [('duplicate id', 'new-74', 'new-1')]

There are multiple bugs here:
- bzr resolve tries to work on multiple conflicts involving the same file with catastrophic results,
- --take-other wasn't the real intent here [1],
- while investigating I encountered several tracebacks even when trying to resolve a single conflict (I'll file specific bugs for that).

[1] Many conflicts occurred because some files were deleted in the packaging branch for various (valid) reasons but modified in the trunk. All of them, in this case, need to be resolved with --take-this (i.e. keep the file deleted, ignore the modifications).

This means that the blank 'bzr resolve --take-xxx' is too broad and bzr probably needs to provides a way to set the resolve action at the file or directory level so that 'bzr resolve --auto' can respect these settings.

Oh, for the record, 62 conflicts need to be resolved here, so even resolving them one by one manually just doesn't scale, especially considering that the previous, successful, merge occurred one *week* ago.

I've got a fix in the pipe.

The root issue is that we generate two conflicts involving the same file-id in some circumstances where a single one should be enough. The symptom here is therefore a fallout.

The circumstances are a file is deleted in one branch and renamed *and* modified in the other. In this case we generate a PathConflict for the deleted/renamed part and a ContentsConflict for the deleted/modified part. The later should be enough.

The fix I have filters out the path conflicts when there is a corresponding contents conflict (since it should be enough for the resolution needs in all cases). I have to write tests to verify I'm not missing some edge cases here. I also have to check whether the user get sufficient feedback to realize the file has also been renamed (which may occur before, after or at the same time as the modifications) but that may not be relevant here.