Fix for #668 - using Java reflection in ScalaDsl

The previous implementation was using Scala 2.9 reflection via
Manifest[T] to extract the function parameter types using the erasure
method (renamed to runtimeClass in Scala 2.10).

The problem with this approach is that Manifest.erasure provides the
runtime java.lang.reflect.Type, which means the type has been erased of
paramterized type info.

The ParameterInfo class relies on the ParamaterizedType information
to determine how to auto populate Step arguments of type
java.util.List<T>. When using java Lists from the Scala DSL, this logic
would fail.

As ParameterInfo's implementation is entirely based on the Java
reflection API, it makes more sense to use Java reflection in the
implementation of Scala DSL as it will be compatible with the logic in
core.

This change uses Java reflection on the Scala Function objects to
extract the ParameterizedType information, which also simplifies the
code.

The manifest is no longer used by the register method, but seems to
still be required on the function definitions by another part of the
code so these have been left in place.

The functionParams method has to filter out JVM bridge methods to ensure
the correct version of the apply() method (with type parameter
information) is captured.  Function objects only have one defined method
named apply() so taking the head of the list should always be safe.
Updating gen.scala to reflect changes in previous commit

Not sure if the code generation is still being used as the functions in
ScalaDsl seem to have diverged slightly from what this script would
generate in it's current form.

Updating it to reflect the new logic anyway in case it's still required.

Pushing this as a separate commit to allow cherry picking.
Transforming Gherkin tables into java.util.List<T> broken in Scala DSL. Closes #668, #669