Ignore gem options when resolving cookbook gem metadata

[tas50]

Fixes chefspec#1016

Problem

A cookbook's gem metadata accepts the same trailing options Hash a Gemfile does:

gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw]

Chef::Cookbook::Metadata#gem stores the raw args, and Chef writes them into a generated Gemfile where gem(*args) handles the Hash natively. ChefSpec's override instead passes them to Gem::Specification.find_by_name as version requirements:

::Gem::Specification.find_by_name(gem_name, gem_requirements)

Gem::Requirement then raises BadRequirementError, which the rescue ::Gem::MissingSpecError does not catch, so the whole converge fails:

Gem::Requirement::BadRequirementError:
  Illformed requirement [{platforms: [:mingw, :mswin, :x64_mingw]}]
# lib/chefspec/extensions/chef/cookbook/gem_installer.rb:24:in 'locate_gem'

This also fires for a dependent cookbook's metadata, so it can break a run for a cookbook the author does not control.

Fix

Drop the options Hash before resolving, keeping only the version requirements.

Testing

Adds a cookbook_gems acceptance example whose metadata.rb declares gems both with and without an options Hash.

• With the fix: 2 examples, 0 failures
• With the fix reverted: 2 examples, 2 failures (BadRequirementError)
• Unit suite: 197 examples, 0 failures

Worth noting separately: a gem restricted to platforms that do not match the current one now falls through to the existing "No matching version found" warning (chefspec#1015). Skipping non-matching platforms outright would be a reasonable follow-up.

[tas50]

CI on this PR is red for an unrelated reason: main's bundle cannot be installed on Linux, which breaks every job before any test runs. That is fixed separately in #56, which is green across Ruby 3.1 to 3.4. This PR should go green once #56 lands and this branch is rebased.

Locally, against a working bundle, this branch passes rake unit and the acceptance examples.