I don't think ```OptparseResult``` should derive from ```InterfaceOption``` because an interface option represents an optparse option that a user can provide as input on the command line, but we have cases where results aren't necessarily tied to actual optparse options (for example, printing some results to stdout). Thus, it's weird to have a class that has things like a type, action, name, short name, etc. when that information is not ever used to build an interface for the "option". See some examples in biom where this is happening.

If we go with the hierarchy I described above, we could have ```OptparseInputOption``` and ```OptparseOutputOption```, which would handle converting optparse command-line input into a command's input, and a command's output back into something consumable on the command-line side, respectively. Then the interface config files would have a single list of options, where some of them would be ```OptparseInputOption```s and some would be ```OptparseOutputOption```s. Or we could keep two separate lists like we currently have.

Sorry if this is confusing- it is very difficult to describe this abstract stuff in a comment. Not sure if I'm making any sense...