Support CharSequence argument for Fallback String-to-Object Conversion

[sbrannen]

Prior to this commit, the "Fallback String-to-Object Conversion" support for parameterized tests supported factory constructors and methods that accepted a single String argument.

This commit relaxes that restriction to support factory constructors and methods that accept either a single String argument or a single CharSequence argument, since the original source String can always be supplied to an Executable that accepts a CharSequence.

Note that this change is available to third parties via ConversionSupport in junit-platform-commons, which junit-jupiter-params utilizes.

• Closes Extend fallback conversion to support CharSequence factory arguments #4815

[sbrannen]

In my opinion, both the feature and the implementation are straightforward.

However, after having put a little more thought into it, I believe we may want to alter the implementation to support backward compatibility.

For example, if an existing code base has overloaded from(String) and from(CharSequence) factory methods, JUnit would have used from(String) prior to 6.0. However, with this change in 6.0, JUnit will ignore both from(...) factory methods, since we only honor a single, unambiguous factory method.

Thus, we should ideally make a first pass to find String factory methods/constructors to support backward compatibility and then make an additional pass to find CharSequence factories.

In other words, I think this new feature should effectively be a "fallback for the fallback". 😉

I'm happy to implement that, but I wanted to bring up the topic for discussion first.

[sbrannen]

For example, if an existing code base has overloaded from(String) and from(CharSequence) factory methods, JUnit would have used from(String) prior to 6.0. However, with this change in 6.0, JUnit will ignore both from(...) factory methods, since we only honor a single, unambiguous factory method.

I've marked this PR as a draft until I've reworked the implementation to avoid introducing that regression.

[sbrannen]

For example, if an existing code base has overloaded from(String) and from(CharSequence) factory methods, JUnit would have used from(String) prior to 6.0. However, with this change in 6.0, JUnit will ignore both from(...) factory methods, since we only honor a single, unambiguous factory method.

I've marked this PR as a draft until I've reworked the implementation to avoid introducing that regression.

I have addressed this, force pushed, and removed draft status.