Add support for groups in the default HelpPrinter

[mickael-menu]

Fix #134

@alecthomas It is still lacking support for grouped flags, I wanted to check with you that this PR is welcome and on the right path first.

Here's what's implemented so far:

• Ungrouped commands are displayed first, under a "Command:" group.
• Each group is printed in order of appearance.
• Tree mode ignores group for now.
  • This part is not so easy to implement, maybe that's a reasonable limitation.

I think it could be useful to add some group metadata as well. In this case, the group tag would be a key referencing a declared Group metadata. We could store:

• The group title, in case it's long and to be able to modify it in only one spot.
  • Git headings are quite long, e.g. start a working area (see also: git help tutorial)
• A short help message displayed under the group title.

  Filtering:
  Options used to filter the items in the list.
  
      --name   Filter by name
      --color   Filter by color
  

I'm not sure what would be the best place for such metadata. Maybe an Option?

[mickael-menu]

I initially thought that subcommands would automatically inherit the group of their parents, from there:

kong/build.go

Lines 76 to 79 in 2479d83

	// Assign parent if it's not already set.
	if subf.tag.Group == "" {
	subf.tag.Group = tag.Group
	}

But subcommands are actually escaping the for loop from here:

kong/build.go

Line 62 in 2479d83

continue

I didn't want to mess too much with this part, so I added this ClosestGroup() function to do the job.

[alecthomas]

Looks good!

That's a really great idea about the titles, the main reason I hadn't kept going with this is that putting long group titles in struct tags is not awesome.

I think, as you say, a function option such as kong.Groups({key: title}) would be a great solution.

[mickael-menu]

Sounds good, I'll keep going then!

[mickael-menu]

@alecthomas Ready for review, let me know if I missed something 👍

[alecthomas]

Per other comment, the groups should be accessible through the model, in which case this should be unnecessary.

[alecthomas]

Same thing for all the other locations.

[alecthomas]

This should go into model.go, and be returned by the existing group related model methods.

[mickael-menu]

Just to clarify, you want something like this?

type Node struct {
    ...
-    Group string  
+    Group *Group
}

type Group struct {
+   // Key is the `group` field tag value used to identify this group.
+   Key string
    Title string
    Header string
}

And have the key -> Group resolved during parsing in build.go?

[alecthomas]

Exactly.

[alecthomas]

Formatting looks good!

[alecthomas]

Nice, thanks!

[alecthomas]

This is awesome.

[jotaen]

🎉 This PR makes me really happy, it came exactly at the right time for me 😄 Thank you @mickael-menu!