Weird behavior with getopt for invalid user input

[Andrew Pennebaker]

In many getopt implementations, the -h/--help banner is printed 
when the user supplies invalid arguments. However, D's getopt 
instead throws an exception, printing a stack trace and confusing 
some non-technical users.

That's okay, we can catch GetoptException and try to print the 
usage information instead. But that also doesn't work so well, as 
the getopt spec cannot bind to a variable when an exception is 
thrown. Again, other getopt implementations tend to separate the 
getopt spec object construction from argument validation into 
separate function calls, which gives the programmer more 
flexibility for how to handle any errors.

Sigh, when I manually `defaultGetoptPrinter(format("Usage: %s 
[OPTIONS]", program), opts.options);`, I think I can do this by 
typing out the getopt spec a second time, overriding the args 
with ["-h"]. But this is starting to require a ridiculous number 
of hacks, when getopt could have just executed -h on error, as 
many users would expect.