Allow defining a help string for an option's parameter value.

pkg/args/CHANGELOG.md

Index: pkg/args/CHANGELOG.md
diff --git a/pkg/args/CHANGELOG.md b/pkg/args/CHANGELOG.md
index cb8acb9419b213fa0f5423a93ad8caefe7696128..5349ae2fdbce9ff967ca6c259a8ce11caf818c39 100644
--- a/pkg/args/CHANGELOG.md
+++ b/pkg/args/CHANGELOG.md
@@ -1,3 +1,7 @@
+## 0.11.1
+
+* Options may define `valueHelp` which will then be shown in the usage.

[nweiz, 2014/07/02 19:41:32]

"valueHelp" -> "helpValue"

I find both of these names confusing though. What do you think about
"valueName"?

[Bob Nystrom, 2014/07/07 20:37:34]

I want to include "help" in the name to make it clear that that's what it's for
and that it doesn't have any other effect. I think "valueHelp" matches
"allowedHelp" pretty well.

[nweiz, 2014/07/07 20:52:00]

I think "help" communicates that it's some sort of prose documentation, rather
than an individual name. That's what it means when it's used elsewhere in this
API. "name" still communicates that it's used for documentation but also that
it's supposed to be only one or two words that name the value.

[Bob Nystrom, 2014/07/07 23:16:06]

.addOption() already has a parameter called "name" which is definitely not used
just for documentation, so I don't think it conveys that. I want to avoid:

var parser.addOption("foo", name: "bar");
var results = parser.parse(args);
results["bar"]; // User is surprised this doesn't work.

I'm not crazy about "helpValue", but it's the best I could come up with that
makes it clear the parameter doesn't "name" the option in any way outside of
usage.

+
 ## 0.11.0
 
 * Move handling trailing options from `ArgParser.parse()` into `ArgParser`