largefiles: drop the unused lfcommands._addchangeset()

largefiles: use the convert extension for 'lfconvert --to-normal' The logic in the convert extension is more advanced, supporting extra features like converting revision IDs in 'extras' (e.g. 'amend_source'), supports updating hashes in commit messages, and outputs an SHA map file. Rather than try to duplicate all of that, just use the existing code. Even though the convert extension supports user supplied options like filemap, etc, those features aren't available on the lfconvert interface. Therefore, it is safe to use the filemap mechanism (in memory) to handle the standin -> file rename. The convert extension handles the destination locking for this path. There was a comment in test-lfconvert.t about the hash on rev 5 being different because it was doing a better job than "hg remove" + "hg merge" + "hg commit". It isn't clear to me what was happening or why, but now the hashes match the original repo exactly after a roundtrip, which seems like a good idea. If there really was something beneficial about the previous behavior, perhaps merge can be changed so that everyone benefits. Converting to a largefiles repo still uses the original (limited) lfconvert logic.

bundle2: add generic debug output regarding generated interruption If we are about to hide the detailed debug output, we need some generic debug message to replace it in a concise way.

bundle2: add generic debug output regarding generated parts If we are about to hide the detailed debug output, we need some generic debug message to replace it in a concise way.

bundle2: add generic debug output regarding generated bundle If we are about to hide the detailed debug output, we need some generic debug message to replace it in a more compact way.

bundle2: add debug output for part generation The part generation process was lacking a ui object and could not produce debug output. It seems valuable to have some debug output on this part too, especially now that we are planning to be able to hide it in the default --debug output.

bundle2: handle new line in 'indebug' function Now that we have a prefix, it make sense to assume all output will be on a single line.

bundle2: prefix all unbundling debug message with 'bundle2-input:' This make the origin of the message more explicit.

bundle2: introduce a specific function for debug messages while unbundling The bundling process is very verbose, we would like to be able to hide such output behind a configuration flag and have it more explicitly referencing bundle2. The first step is to gather all these messages in a dedicated function.

bundle2: add an informative comment to the capability dict It is fairly easy to get confused by capabilities "missing" from this dict. We make it clear the dict is not the whole story.