Rearrange / retitle fields for the per-quantity offer types and support matching any product

Patch attached with one difference from the screenshot: the suffix on the "Discounted by" field now says (e.g. .2 for 20% off) in its parentheses.

Hey Dan, removing the required value from the trigger products field doesn't need to be the same patch, but for simplicity's sake I rolled that update and the related rules change into the same patch / update function.

The basic idea here is that by leaving the trigger product reference field empty, any product will count as a trigger product. I do this in the Rules action by adding a check for empty($trigger_product_ids) alongside any check for in_array($product_id, $trigger_product_ids). I have this need for a client who basically wants to setup a free gift offer on every single purchase for a limited time.

I've tested the patch, though I'm not sure I followed all of what's going on in the manifest. I also wonder if we don't need a way to prevent products discounted by another offer from triggering a second offer. (For example, I setup two BOGO offers, and by adding both offer products to the cart, they triggered each other's discount.) I'll open a separate issue for that, but my hunch is we can use a static variable or something in the action to rule products out of the manifest that are discounted already.

You'd have to test it against the latest Commerce Discount dev I believe, as the float fix (and others) had to go in that module. Lemme review the patch real quick as well - I started work on another feature (adding existing free offers to the cart when triggering products are added) and I can't remember off the top of my head if I updated any of the labels / descriptions as a result.

Ok, looked into it and saw I had actually progressed beyond this. I should've used an issue branch and made incremental commits, but unfortunately I thought of it too late. So the attached patch here contains all the previous changes (with one or two adjustments to labels / descriptions), but it also adds support to automatically add a BOGO offer product to the cart. I think I just did it all in one because it also involved the addition of a new field on the offer type to govern the behavior.

I've attached an interdiff that demonstrates the changes between the patches in #2 and #5. I've done fairly extensive user testing, but I'm happy to walk through this with you if you'd like. It made me think two things: 1) we should consider migrating this functionality into Commerce Discounts so we can add tests, and 2) we should consider making an object that negotiates the applicability of an offer and instructs the module how to actually apply it. This would avoid the need for code duplication in places like the add to cart hook vs. the rules action.

Here's the latest image of the BOGO form:

Updated patch attached that doesn't use empty() on the return value of a function.

Updated patch that makes use of a new feature in Commerce Discount to log in a BOGO which line items played into the discount line item amount. This allows us to begin to recognize these discounts in relation to product line items in the cart after the fact.

Update patch to set the discount name when an offer product is automatically added via a BOGO style discount.

Leaving a note here in case I don't get to this tonight: the function commerce_discount_extra_commerce_cart_product_add() needs to properly initialize the RulesState parameters by loading the event outside of the loop and then adding the order to the RulesState inside the loop.

  // Load the sell price calculation event.
  $event = rules_get_cache('event_commerce_discount_order');

  // ...

    // Evaluate each rule's conditions to see if the discount would apply to the
    // current shopping cart.
    $state = new RulesState();
    $vars = $event->parameterInfo(TRUE);
    $state->addVariable('commerce_order', $order, $vars['commerce_order']);

Thanks, Andy, worked the fix into my local branch.

Aaaand, committed.