Add NilClass#=~ - #6999

String#=~ dispatches an argument that is neither a Regexp nor a String as
other =~ self, which is what CRuby's rb_str_match does too. CRuby has a defined
answer for nil because NilClass#=~ exists and returns nil; mruby had no =~ on
NilClass, so the dispatch raised NoMethodError. Kernel#!~ (mrblib/kernel.rb:38)
is !(self =~ y), so it inherited the same hole: !~ is listed among nil's methods,
and calling it raised.

"abc" =~ nil   # CRuby: nil,  mruby before: NoMethodError
nil !~ /a/     # CRuby: true, mruby before: NoMethodError
:a =~ nil      # CRuby: nil,  mruby before: NoMethodError (via Symbol#=~ -> String#=~)

nil is the only gap. Object#=~ was removed in Ruby 3.2, so every other receiver
without its own =~ raises NoMethodError in CRuby as well, and mruby already agrees.

"abc" =~ 1                  # CRuby: NoMethodError, mruby: NoMethodError
"abc" =~ Object.new         # CRuby: NoMethodError, mruby: NoMethodError
Object.new.respond_to?(:=~) # CRuby: false
nil.respond_to?(:=~)        # CRuby: true

Why the core and not an mrbgem

=~ is not an ISO method of NilClass (ISO 15.2.4.3 lists &, |, ^, nil? and
to_s), so CONTRIBUTING.md asks for a reason to add it to the core. mruby-object-ext
would otherwise be the natural home: it already extends NilClass with to_a, to_h,
to_i and to_f in a ROM table of its own.

The reason is Kernel#!~. It lives in core mrblib and is therefore present in every
build, including one that carries no gem at all, so nil !~ x is a hole no gem can
close. CRuby also answers nil.respond_to?(:=~) with true without loading anything;
making that depend on which gembox a build picks would be a worse surprise than the
space the method takes. That space is 48 bytes of object.o on x86_64: the method goes
into the existing NilClass ROM table, so it adds one entry and one function, and no
irep.

Declaring the entry MRB_ARGS_REQ(1) gives the arity check without a mrb_get_args()
call, the same way false_and() does.

What is in the PR

• src/object.c: nil_match() and its ROM table entry.
• test/t/nil.rb: the core cases, which need no Regexp: any argument answers nil,
  nil.respond_to?(:=~), the !~ path, and the arity check.
• mrbgems/mruby-regexp/test/: the cases that do need Regexp, in the gem that owns the
  dispatch: "abc" =~ nil, "abc" !~ nil, :hello =~ nil, and the NoMethodError
  rows above, which pin that this change does not turn =~ into a blanket type check.
• The header comment of mrbgems/mruby-regexp/mrblib/symbol_regexp.rb named this gap as
  behaviour inherited from String#=~. With NilClass#=~ in place the argument handling
  of Symbol#=~ agrees with CRuby on every argument type, so the comment is rewritten.

=~ deliberately keeps dispatching rather than type-checking its argument, unlike
match and match? (#6988): a blanket TypeError would break the nil and the
NoMethodError rows above, both of which CRuby answers the way mruby now does.

Compared against CRuby 4.0.6. rake test passes, and prek run --all-files is clean.

Summary by CodeRabbit

• New Features

  • Added support for matching operations on nil, returning nil for all operands.
  • Added support for nil !~ expressions.

• Bug Fixes

  • Improved matching behavior for strings and symbols with non-regular-expression operands.
  • Unsupported operands now raise the appropriate errors, while nil operands return expected results.

• Tests

  • Expanded coverage for matching, negated matching, operand delegation, and invalid arguments.