Let PaymentMethod create a customer profile using a payment profile

In the original code, `payment_method.create_profile` is called only when the source has neither a customer profile nor a payment profile.
This patch removes that check in order to create a customer profile using a payment profile.

Closes #5292
Remove default_notification_payload method

It's unused method.

Closes #5295
Create Spree::Core::ControllerHelpers::Search module test

Closes #5294
Allow for notification of API errors

Due to the way the rescue handlers are setup for the API, there's no easy way to alert Honeybadger/Airbrake/etc of an error in the API. Instead we have to check the client error JSON and debug from that which is not very ideal expecially if we don't control the client code. This is a simple change to let people decorate in a hook on ```error_during_processing``` so that we can notify on error.

This should help me get rid of one more ```class_eval``` and ```alias_method_chain``` in my application.

Thought this was more flexible then to have but open doing the KISS solution below:

```
if defined?(Honeybadger) then Honeybadger.notify()
```

incorporate feedback from jordan, make this proc based

Get rid of more class evals and let people use this as a config via Proc.

Closes #5285
Refactor Spree::OrderContents#add_to_line_item so that the logic of setting the line item price based on the product options is reusable when creating an updating a line item

Closes #5274

Making Spree::LineItem#options= more robust for vanilla line items.

Using assign_attributes rather than iterating through the hash and setting the option values manually
make sure we get the current order for use in the cart as well. Refactored some shared code as well.

Fixes #5300
Remove unused file

Closes #5303
Create Spree::Core::ControllerHelpers::Store module test
Removing non existent items from params to avoid bug when clicking on remove multiple times or when clicking on multiple remove buttons

Fixes #5304
Closes #5305
Simple fix for payment source.

Steps to reproduce the issue:

1. Add an order through the admin interface
2. Attempt to pay via cheque for a user who has a credit card number
stored in their profile.
3. Submit the form

This will 500, because params[:card] is set from the form on the initial
page for the radio button from the credit card profiles.

This is a simple, though incomplete fix for the issue. A proper fix
would be to change the form so that params[:card] is qualified by the
payment_method which it belongs.

There are also likely issues with multiple payment methods which support
profiles, as there is likely to be confusion between them. This should
suffice for now.

Fixes #5209
keep the simple_current_order simple :)
Fix spec.
Revert "Removing non existent items from params to avoid bug when clicking on remove multiple times or when clicking on multiple remove buttons"

This reverts commit 466b3fecf71bc38714dd637e04a5bd4ac0a6cc5d.

This commit broke the build.
Fixes regressions in sprockets >= 2.1.4

Fixes #5311
Fixes #5313
Removing non existent items from params to avoid bug when clicking on remove multiple times or when clicking on multiple remove buttons

Skipping filter if there is only one line item being updated

Fixing order controller spec

Dealing with case when line items attributes is nil

Fixes #5318
Fix item_adjustment_spec.rb

Test after tax_adjustments callback instead of after promo_adjustments, which was testing a few lines earlier
Fixes #5320
Only cancel cancellable shipments.

Fixes #5321
Fixes #5299
Update Ruby hash syntax to 1.9

Create Spree::Core::ControllerHelpers::StrongParameters test
Fixes #5322
Allow partial emails when searching for orders
Fixes #5314
:scissors: