When there is a conflict between the type hint from the regular expression
and the method prefer the the parameter type associated with the regular
expression. This ensures we will use the internal/user registered parameter
transformer rather then the default.

Unless the parameter type indicates it is the stronger type hint.

Reasoning:
1. Pure cucumber expression users will not notice this in either scenario.
2. Pure regular expression users will benefit because
   `BuiltInParameterTransformer` can now seamlessly transform any captured
   values. (For all built in types useRegexpMatchAsStrongTypeHint is
   explicitly set to false.)
2. Regular expression users that define a default transformer have little
   need to define parameter types. The default transformer should be
   sufficiently powerful to meet their needs and will often allow users to
   add custom creation methods e.g. Jacksons @JsonFactory.
3. Users who mix regular and cucumber expressions may run into conflicts
   when a registered cucumber expression and unregistered happens to
   collide. However this was the situation before this flag was added.
4. Regular expression users who define custom parameter types do so with
   the expectation that the parameter will be matched. Subverting this
   expectation when the method signature does not match may result in a
   parameter transformer that is unable to convert to the desired type.
   Leaving the user puzzled as to why his transform was ignored.

Fixes: #658

When there is a conflict between the type hint from the regular expression
and the method prefer the the parameter type associated with the regular
expression. This ensures we will use the internal/user registered parameter
transformer rather then the default.

Unless the parameter type indicates it is the stronger type hint.

Reasoning:
1. Pure cucumber expression users will not notice this in either scenario.
2. Pure regular expression users will benefit because
   `BuiltInParameterTransformer` can now seamlessly transform any captured
   values. (For all built in types `useRegexpMatchAsStrongTypeHint` is
   explicitly set to false.)
2. Regular expression users that define a default transformer have little
   need to define parameter types. The default transformer should be
   sufficiently powerful to meet their needs and will often allow users to
   add custom creation methods e.g. Jacksons @JsonFactory.
3. Users who mix regular and cucumber expressions may run into conflicts
   when a registered cucumber expression and unregistered happens to
   collide. However this was the situation before this flag was added.
4. Regular expression users who define custom parameter types do so with
   the expectation that the parameter will be matched. Subverting this
   expectation when the method signature does not match may result in a
   parameter transformer that is unable to convert to the desired type.
   Leaving the user puzzled as to why his transform was ignored.

…ver-parameter-type