It doesn't make sense for @Option to have multi-value setting.

This is because whether a setter can handle multiple invocations
well (by retaining all the values) or not (usually by having the last
invocation overwrites all the previous values) are determined
by Setter and setter alone, so asking the user to configure that makes
no sense.

MultivaluedTest indicates that the author of this part of the code seems
to have been thinking about concatanating values or something like that,
but if someone wants that kind of unusual parsing, he should be writing
OptionHandler.
added Setter that handles an array
Fixed the way MapOptionHandler works

The problem with MapSetter is that it has too much logic in it. Setters are not meant to be doing too much --- it's merely there to abstract away the difference between fields and methods. Anything that involves parsing should be OptionHandler.

The reason MapOptionHandler wasn't done cleanly is because setting a Map requires a get access of the field value. So we should expose this from FieldSetter.
Added Setter.asFieldSetter()

In light of issue #16, I'm allowing OptionHandler to access the underlying FieldSetter.