This allows the CLI to expose options that the renderers can offer.
These options are limited (string, int, bool and bytes), so no lists
or choices, etc.
Each renderer's options are also global options, meaning they're always
present (although grouped). There's two ways of handling this:
a) Prefix each option with the renderer's name, duplicate options are
unique
b) Deduplicate options with duplicate names and prefix 'renderer'
The current choice is a) because b) might confuse people that an option
which only applied to one renderer would be available for all, but
comes with the inconvenience that users must adapt the option name for
those that are duplicated with the same meaning.
This is at least functional and extendable in the future but still a bit
clunky. We could have brought the entire configuration mechanism into
play, but each renderer would require a context and a config_path and
so on, meaning massive overkill and a non-addition-only API change.
This highlights that the FileHandler class can also be seen as a method
similar to open, and it removes unnecessary context managers, allowing
plugins to close files as they wish (they must, however, remember to
close the file for it to be committed).
This separates out a new PDBUtility class that can take a (contiguous) layer and MZ
offset, and produce identify, download if necessary and load the
appropriate symbol table (if any).
Previously, for segmented layers, no chunk larger than a full segment
was scanned. Now, we combine contiguous segments up to
scanner.chunk_size (or until a non-present segment) in order to scan it.
This may be slightly slower (by concatting the data together) but gives
results of hits across page boundaries (the point of the scanning
capability), whereas previously each page was scanned individually.
Mike Auty