Match GET case-insensitively when deciding an action is a link

[6temes]

A custom action declared with http_methods [:GET] routed and authorized fine but
never appeared in a menu, and rendered as plain text rather than a link in
breadcrumbs. Both helper call sites tested membership exactly, and
%i[GET].include?(:get) is false. Nothing raised — the action was simply unreachable
from the UI, which is the part that makes it expensive to notice.

http_methods is host-supplied, so the casing is not this engine's to control.

Routing itself was never affected: Rails' verb matchers normalise case before
comparing against request_method, so :GET, "get" and "GET" all route. Only
the two helper checks were case-sensitive.

The question both call sites actually ask is not "does this respond to GET" but "can
this be rendered as a plain link, or does it need a button because the verb mutates",
so the predicate is named for that. include?(:get) stays as the first disjunct: it
is the common case and menu_for is on a hot path.

Unapplied review findings

• Advisory — lib/rails_admin_next/config/actions/base.rb — linkable? is a
  plain method, not a register_instance_option, so a host cannot override "is
  this action a link" independently of http_methods. Matches the pre-existing
  inline checks, so not a regression, but there is no hook for a host that wants
  a GET action rendered as a button.
• Advisory — no spec covers http_methods being empty or carrying a nil entry.
  Unexercised before this change too.

Closes #31