@Param and BodyParserEnginePost should be able to decode to Lists and arrays

[tbroyer]

Parameters can be multivalued (e.g. ?listbox=value1&listbox=value2 for a <select multiple> or a group of <input type=checkbox> with the same name), so they should be decoded into lists or arrays.

E.g. param1=1&param1=2 could be decoded into:

• as an Arrays.asList("1", "2") into a List<String>, Collection<String> or Iterable<String> field/argument
• as an ArrayList with values 1 and 2 into a List<Integer>, Collection<Integer> or Iterable<Integer> field/argument, and similarly for doubles, floats, longs and booleans.
• as a String[] into a String[] or Object[] field/argument
• as an int[] or Integer[], and similarly for doubles, floats, longs and booleans.

Open question: what to do with Object fields/arguments? getParameterMap uses a String[] for the values, so it could be used as-is; but List<String> also makes sense.
In #86 I added getParameterValues as a List<String>, so a List<String> would also make sense.

As for the implementation, a few APIs would have to change from Class<?> to Type or Guava's TypeToken to be able to capture the generic type parameters of fields/arguments.
I'd otherwise propose doing the above transformation within ParamParser (as an abstract class) or ParamParsers (as a helper method), so be used in both BodyParserEnginePost and ControllerMethodInvocation.

[raphaelbauer]

Makes really a lot of sense!
Do you think

• we can still keep something like @param("myparam") String myParam in the controller => if there is only one myParam in the request? It seems a bit simpler than having Param("myparam") List myParam.
• If you add the Lists it would be cool if the java doc clearly states the reason why there is a List and not only a single value (just copying the above issue is of course enough).

[raphaelbauer]

Fixed. Closing this one...