options for incremental reporting and/or internal timeout handling

When diffoscope takes a very long time and is killed (e.g. the 120 minute timeout on tests.reproducible-builds.org), you typically end up with no meaningful output from diffoscope, as I understand it.

It would be very nice if diffoscope could at least report what it has already "figured out" in these situations... e.g. it doesn't typically take long for diffoscope to determine the diff output on the .changes or .buildinfo files, but recursively parsing each of the referenced .deb files might take a very long time. If it could output some data, as soon as it finds it, this could be useful.

Additionally or alternately, if diffoscope had a --timeout=X option that was set with a little lower threshold that the timeout process it is started with, diffoscope could at least report what it already discovered when it reaches it's own timeout, before it gets killed by the controlling process.

Similarly, a --max-time-per-file=X commandline flag, where diffoscope would spend at most X amount of time on each file, and then move on to the next file to compare, and then only report the file differed but took too long to process. this would allow it to at least report which files differed, and files that process in a reasonable timeframe would have meaningful data.

Implementing some of the above could be especially helpful in cases where one file takes a very long time to compare, but another quicker to compare file is triggered by the same cause... fixing the cause might allow both to become reproducible or at least differ in smaller ways that take less time to compare in future iterations.

Thanks!