Allow keyword arguments to match an expectation expecting *only* positional arguments

[floehopper]

TODO:

• Address to-do list in WIP commit
  • Try to simpify logic in PositionalOrKeywordHash#matches?
  • [ ] Maybe use keyword arguments for PositionalOrKeywordHash constructor
  • Check whether all relevant scenarios are covered by tests
  • Check whether this has any effect on Expectations with String keys misidentified as keyword arguments #594 (I don't think it does)
• Check the examples below

This is a (very belated) possible fix for #593.

According to these docs:

Note that Ruby 3.0 doesn’t behave differently when calling a method which doesn’t accept keyword arguments with keyword arguments. For instance, the following case is not going to be deprecated and will keep working in Ruby 3.0. The keyword arguments are still treated as a positional Hash argument.

def foo(kwargs = {})
 kwargs
end

foo(k: 1) #=> {:k=>1}

This is because this style is used very frequently, and there is no ambiguity in how the argument should be treated. Prohibiting this conversion would result in additional incompatibility for little benefit.

This solution takes an alternative approach to #605 which depended on #532. Instead of basing the logic in Mocha::ParameterMatchers::PositionalOrKeywordHash#matches? on the original method signature, it bases it on the expected arguments, i.e. the parameter matchers. Since keyword arguments can only appear after all positional arguments, we can detect an expectation which only expects positional arguments by checking whether the last parameter matcher is expecting a positional Hash or a keyword Hash. If it's expecting a positional Hash then we can assume the expectation only expects positional arguments and thus it should successfully match keyword arguments with that positional Hash without issuing a deprecation warning.

I think my work on #532 at the time must've blinded me to the idea that we needed to base the logic on the original method signature which is a considerably more complicated undertaking. Although the solution in this PR might not be perfect, I think it's probably an improvement and we can look at ensuring that expected parameters match the original method signature as a separate issue which relates to #149, #531 & #532.

Before fix

foo = mock('foo')
foo.stubs(:bar).with(123, { baz: 456 })

Mocha::Configuration.override(strict_keyword_argument_matching: false) do
  foo.bar(123, { baz: 456 }) # => matched *without* deprecation warning
  foo.bar(123, baz: 456) # => matched *with* deprecation warning
end

Mocha::Configuration.override(strict_keyword_argument_matching: true) do
  foo.bar(123, { baz: 456 }) # => matched *without* deprecation warning
  foo.bar(123, baz: 456) # => did not match
end

After fix

foo = mock('foo')
foo.stubs(:bar).with(123, { baz: 456 })

Mocha::Configuration.override(strict_keyword_argument_matching: false) do
  foo.bar(123, { baz: 456 }) # => matches *without* deprecation warning
  foo.bar(123, baz: 456) # => matches *without* deprecation warning
end

Mocha::Configuration.override(strict_keyword_argument_matching: true) do
  foo.bar(123, { baz: 456 }) # => matches *without* deprecation warning
  foo.bar(123, baz: 456) # => matches *without* deprecation warning
end