Use of subcommands in the CLI syntax

I'm late with these comments, but anyway, the issue of subcommands needs some long-term thinking. On one hand, it's nice to be able to do just unibeautify file.c. On the other hand, this makes the unibeautify command's syntax harder to extend in the future.

The current unibeautify command supports giving the filename as unibeautify foo, but also supports the subcommand unibeautify support. I would strongly encourage us not to mix these two usages. Shell commands should be easy to call from shell scripts and other programs, so it's customary to do things like unibeautify $file, where the value of the variable $file can basically come from anywhere. Usually this is protected as unibeautify -- $file so that $file is not interpreted as a command line option if it happens to start with a dash (the -- argument disables option parsing for the rest of the command line, any options that come after it are treated as ordinary arguments even if they start with a dash).

Anyway, the overarching principle is that any command line argument can come from a variable, so an argument at a particular position should always have only one kind of meaning. So we should have either:

1. unibeautify $file and unibeautify --supports, or:
2. unibeautify beautify $file and unibeautify supports

For the same reason, command line flags should not take a variable number of arguments. I don't think we have any of these :)

Of course, the subcommand names are up for debate :)