anchor.diff:  * CommandLine::populateCommand
   
   
  -== Usage Help Format Improvements
  -This release contains various bugfixes that improve the usage help format for multi-value options and collections.
  -For example, for Maps that don't have a `paramLabel`, picocli now shows key type and value type instead of the internal Java field name.
  -
   == Better Subcommand Support
   
   This release adds new `CommandLine::parseWithHandler` methods. These methods offer the same ease of use as the `run` and `call` methods, but with more flexibility and better support for nested subcommands.
   
   // image:https://www.intersoft.no/wp-content/uploads/2015/11/duplicate.png[]
  -image:http://picocli.info/images/strong_leadership.jpg[]
  +image:strong_leadership.jpg[]
   
   Consider what an application with subcommands needs to do:
   
   1. Parse the command line.
   2. If user input was invalid, print the error message and the usage help message for the subcommand where the parsing failed.
  -3. If parsing succeeded, check if the user requested usage help or version information. If so, print the requested information and exit.
  +3. If parsing succeeded, check if the user requested usage help or version information for the top-level command or a subcommand. If so, print the requested information and exit.
   4. Otherwise, execute the business logic. Usually this means executing the most specific subcommand.
   
   Picocli provides some building blocks to accomplish this, but it was up to the application to wire them together. This wiring is essentially boilerplate and is very similar between applications. For example, previously, an application with subcommands would typically contain code like this:
  
positive.code:     }
  
      public static void main(String... args) {
          CommandLine.run(new AppWithHelp(), System.err, args);
      }
  }
  ----
  
  When executed with `--help`, the program prints usage help:
  
  //[code,shell]
  //----
  //$ java AppWithHelp --help
  //
  
negative.code:     // 2. handle incorrect user input for one of the subcommands
      // 3. automatically print help if requested
      // 4. execute one or more subcommands
      new CommandLine(new YourApp()).parseWithHandler(new RunLast(), System.err, args);
  }
  ----
  
  The new convenience method is `parseWithHandler`. You can create your own custom handler or use one of the built-in handlers. Picocli provides handler implementations for some common use cases described below.  All of these implement automatic help: if the user requests usageHelp or versionHelp, the requested information is printed and the handler returns without further processing.
  
  The built-in handlers are `RunFirst`, `RunLast` and `RunAll`:
  
  * `RunFirst` only runs the *first*, top-level, command (if it implements Runnable or Callable) and ignores subcommands.
  * `RunLast` only runs the *most specific* subcommand. For example, if the user invoked `java Git commit -m "commit message"`, and `commit` is a `Callable` subcommand, only `Commit::call` is invoked. `RunLast` is now used internally by picocli to implement the existing `CommandLine::run` and `CommandLine::call` convenience methods.
  * `RunAll` invokes `run` (or `call`) on the *top-level command and all subcommands* that appeared on the command line (if they implement Runnable or Callable).
  
  There is also a `parseWithHandlers` method, which is similar but additionally lets you specify a custom handler for incorrect user input.
  
  
  === Improved `run` and `call` Methods
  