Improve promotion condition API

[mamhoff]

Summary

This changes the DSL for defining promotion conditions. I know we don't love changing APIs, but hear me out - it becomes simpler and way more straightforward, and the refactor needed is tiny. Also, together with #6357 , we can remove three smelly modules.

The API changes from (this is a real-world example):

class SecondaryShipment < SolidusPromotions::Condition
  include SolidusPromotions::Conditions::ShipmentLevelCondition

  def applicable?(promotable)
    promotable.is_a?(Spree::Shipment) || promotable.is_a?(Spree::ShippingRate)
  end

  def eligible?(promotable)
    send(:"#{promotable.class.name.demodulize.underscore}_discountable?", promotable)
  end

  private

  def shipment_discountable?(shipment)
    shipment.split_shipment_secondary?
  end

  def shipping_rate_discountable?(shipping_rate)
    shipment_discountable?(shipping_rate.shipment)
  end
end

To:

class SecondaryShipment < SolidusPromotions::Condition
  def shipment_eligible?(shipment, _options = {})
    shipment.split_shipment_secondary?
  end

  def shipping_rate_eligible?(shipping_rate, _options = {})
    shipment_discountable?(shipping_rate.shipment)
  end
end

The new API is more concise, and allows us easily to adapt conditions to the upcoming strikethrough prices mechanism, in which we need to discount Spree::Price objects (and also check eligibility of these objects). For checking the eligibility of a price, we need to take into account the current order and the desired quantity of the price's variant, so that can be accomplished with this API - without having to redefine applicable? for a whole lot of conditions.

This is what a strikethrough-price compatible condition would look like:

class AtLeastThreeWithOrderOverHundred < SolidusPromotions::Condition
  def order_eligible?(order, _options = {})
    order.total > 100
  end
  
  # eligibility of prices needs to check the current order, too. 
  def price_eligible?(price, options = {})
    order = options[:order]
    quantity = options[:quantity]
    price.variant.product == preferred_product && quantity > 3 && order_eligible(order)
  end

  # Order eligibility is checked before line item eligibility, so we don't need to check it here
  def line_item_eligible?(line_item, _options = {})
     line_item.variant.product == preferred_product && line_item.quantity > 3
  end
end

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I agree that my PR will be published under the same license as Solidus.
• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have localized any and all user-facing strings that I added to the source code.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.36%. Comparing base (e4ee677) to head (e21a13f).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6360      +/-   ##
==========================================
+ Coverage   89.35%   89.36%   +0.01%     
==========================================
  Files         961      961              
  Lines       20173    20193      +20     
==========================================
+ Hits        18026    18046      +20     
  Misses       2147     2147              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tvdeyen]

I really like this API. Much better and more flexible for future conditions.

Since this is compatible and adds a bunch of useful deprecation warnings, I think this is fine to be shipped with next minor.