Added fiwalk disk image demo - #40

@ajnelson - What's your take? Do we want this, or do we want a more efficient example?

I'm having a look at this now. It looks like mypy no longer likes a test library import strategy, so I'll be fixing that separately.

This branch contains two things:

1. A catch-up merge with main so CI will pass again, after merging PR 41.
2. Type annotations which I think answer the part of initial question from Issue 39 that bites me every few years: roughly "What is supposed to be the type in or out of this DFXML outermost method?" One of my type-review sprees was because after a decade I'd still managed to catch myself mixing up text vs. binary IO in one of the XML ElementTree methods in objects.py.

Now, reviewing the other demo apps, there are other memory-efficient demonstrations that use the read-only SAX model. See e.g. demo_plot_times.py. The tradeoff with those is you have to do your analysis with a SAX mentality, i.e. with XML event-triggered functions.

The main contribution of demo_fiwalk_diskimage.py is that it opens Fiwalk in a subprocess, holds the XML as a binary stream in memory, and then dumps the stream to disk. So, it's somewhat like a pipe for command-line Fiwalk through Python. It doesn't demonstrate manipulating or parsing the XML stream with e.g. the Python XML modules, though each should be able to start from that stream.

I think the demo's worth including within DFXML because there doesn't seem to be a demonstration of fiwalk.fiwalk_xml_stream, but the demo needs comments inlined that summarize that last paragraph.

If you agree, @bitsgalore , would you mind merging the add_fiwalk_disk_image_demo branch into your main and adding a comment or two to the demo script?

@ajnelson-nist With some delay I just added some comments, let me know if this is what you had in mind.

As an aside, for my own use case, in the end I decided to wrap the fiwalk tool directly in a custom wrapper using the -X option. This way I now write fiwalk's output directly to a file, without using any in-memory Python buffers. This also means I don't really need dfxml_python for my particular case, so I'm not entirely sure how useful the demo is in the end.

Anyway, I'll leave it up to your whether you want to proceed with merging this PR or not.

Thank you for the summary. I will merge this once CI finishes. It's good to have the extra annotated demo, and I personally favor more type-annotating.