Current API seems inconsistent

Processing options with sub-commands looks curiously. `ArgParser.parse` method without sub-commands just parses options. But sub-commands require different code organization.

I would suggest something that looks like:

```kotlin
class Opts : Options {
val verbose by option(ArgType.Boolean, "verbose", "v", "Be verbose")
val command by subcommands(Summary(), Multiply())
}

sealed class Subcommand(name: String) : Options(name) {
class Summary : Subcommand("summary") {
val invert by option(ArgType.Boolean, "invert", "i", "Invert results").default(false)
val addendums by argument(ArgType.Int, "addendums", description = "Addendums").vararg()
}
class Multiply : Subcommand("multiply") {
val numbers by argument(ArgType.Int, description = "Addendums").vararg()
}
}

// Usage
val opts = Opts.parse(args)
val command = opts.command
val result = when (command) {
is Subcommand.Summary -> {
val result = command.addendums.sum()
if (command.invert) -1 * result else result
}
is Subcommand.Multiply -> {
command.numbers.reduce{ acc, it -> acc * it }
}
}
```

Such an API will make possible definition of nested sub-commands.

Start by reading the current ArgParser.parse behavior described in the issue and compare it with the proposed Opts, Options, and Subcommand API. Trace how subcommands are currently organized, then determine whether the proposed nested-subcommand usage can be supported while preserving direct option parsing. Done means the shown Summary and Multiply example, including nested subcommands, works as documented.

Written by the indexing model from the issue text.