Add optional scanning support

[JohnQuincyAddingMachine]

Would you be interested in adding the ability to scan a disk with a flatbed scanner after archiving?

I've added a 'scan' function that uses scanimage based on dimensions triggered by a 'disk_size' variable added to each format recipe. There are also some parameters at the top of gw-raw to enable/disable scanning altogether, set the scanner name (for scanimage's use), and to manually override scanning dimensions.

[AkBKukU]

That's a pretty handy addition! But I don't know if I want to integrate that into the main code here or not. I've been trying to think of ways I can parallelize aspects of the process and scanning directly adds a much longer serial task to the imaging work. I'd also like to break out a per-user configuration, like the scanner name, into separate file that won't block pulling updates from git if changed.

Your work on the code also was the first time I encountered the syntax change for imagemagick which is an added complication. My systems all still use the convert,mogirfy, etc type commands for example. We probably need to add support for switching between those at some point which will be another config file issue.

Lastly I've been getting an itch to redo how the logic of this..."tool suite" lets call it, works. As I'm sure you found when updating all the scripts for imagemahick 7, it is kind of a maintenance nightmare. My original plan for a few simple scripts for things kind of exploded in my face. I'm still trying to decided what kind of refactoring is appropriate to fix this. I've also been considering a more massive rewrite in C or Python to either extend FluxEngine's GUI or the gw CLI command into what this is.

I'm going to leave this open because I do like the idea, I'm just unsure of how to best integrate it right now.

[JohnQuincyAddingMachine]

Alright, as someone whose scripting skills are only a few steps past "wtf is a script," at first this one seemed pretty easy to figure out, modify, and update. But the more I poked at it, the more I saw it the way you see it. Fair enough.

I did manage a few quick, minimally violent changes:

• It now has a separate config file and will automatically install a copy for the user if needed.
• I didn't even think to check before (whoops), but it turns out there are a lot of distros using ImageMagick 6.x. So now it checks for the major version and uses whichever of convert/magick is appropriate. (That said, current versions of IM just throw a warning. Not the end of the world, but I think I have it set up so that it won't fall over even if IM removes 'convert' entirely in the future.)
• Scanning function is now more adjustable. The config file has options for the scanner device address, dpi, the format of the file, size overrides, and enabling/disabling the entire scanning system.
• I also wasn't excited about slapping extra dead wait time on the end of a job (especially since some scanners are sloooow). Since it's the last process anyway, scanimage now runs in the background. Maybe a little too quick and dirty a way to go about it, but it at least lets the user get started ripping the next disk without waiting around for the scanner to finish.

What got real messy real quick was trying to adjust it to add configurability to the directory structure. Some functions use absolute directories, some use relative, some cd into a directory before doing things, etc. All fixable, but if you're considering going in a different direction anyway, maybe not worth the trouble.