dgit: Disregard *_multi.changes for .changes ambiguity purposes

dgit: Disregard *_multi.changes for .changes ambiguity purposes

The changes file ambiguity problem arises because dgit does not know
what architecture changes file the build is going to generate.  (To
know that it would have to delve even more into the command line
options the user is passing through dgit to the builder.)

dgit --always-split-build generally makes a _multi.changes file,
because it merges source changes with binaries from the build.  We are
going to make --always-split-build the only way things are done.  This
would result in lots more situations where --rm-old-changes is needed.

However, actually, we can assume that the builder does not generate a
*_multi.changes.  That will allow us to spot the builder-generated
changes file even if there is already a dgit-generated *_multi.changes
file from a previous build.

So: disregard _multi.changes, both when pre-checking for confusing
files, and when actually figuring out what the build produced.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>