Append lib_name to dummy databases

Avoid conflict between test databases for spree core and extensions for
example on the same host
Set cost in Shipment#add_shipping_method

Running into weird total issues after https://github.com/spree/spree/commit/a7f16ac85ee7b250341eeb131a518922d931dd3d
See failing spec in https://github.com/spree/spree-adyen/pull/3
Display user addresses form in a separate page
Add shipments association to stock locations.

Conflicts:
	core/app/models/spree/stock_location.rb
Add Shipment#display_final_price.
Show SOLD OUT if a variant is out of stock

Fixes #4480
Use Spree.t(:out_of_stock) in frontend products/show
add searching and paging for admin promotions area

Fixes #4478
Refactor the order import from being a class_eval on Spree::Order from api to a dedicated importer in spree_core to be reused by other parts.

Update the year in the licence files, added licence file to spree_core as well since this was missing.

Fixes #4447
Enable images to be created in the API within the scope of a product/variant
included_in_price tax rates should be applied using the same rules as their 'additional' brethren
Move complex potential application of tax rate logic into its own method

Oh, and add some light documentation around it, too.
Included in price & default zone tax rates should *always* apply

This way, negative adjustments for this tax rate will be applied, due to no other applicable tax rates
Do not apply a negative adjustment for the default tax zone AND a positive adjustment for the order's tax zone if the tax rate is included in the price

This should fix the Spain + France + Kenya problems outlined here: https://github.com/spree/spree/pull/4327#issuecomment-35364926
Call compute_amount to calculate a TaxRate

This is because it has some extra logic in there which will determine what rate to apply correctly.

Oh, and it's used by Adjustment#update, and it never really does make sense to have two linked parts of your system computing things in two different ways now, does it?
use respond_to rather than rescue NoMethodError in Spree::Calculator

NoMethodErrors can be thrown anywhere down the code path from self.send(method, computable) and this will still tell you to implement the method... even though it's already implemented!

respond_to? won't do such terrible things.
Correct default tax calculation for an order with $60 worth of line items

item totals are now $57.14, tax rate is 5% and combine the two and you get $59.997, which is pretty darn close to $60.
Need to call store_pre_tax_amount before computing non-discounted item's price
Display exclusionary tax amounts on shipping rates
reload item in ItemAdjustments to ensure adjustments are present

I was seeing a situation today where a shipment's refunded tax adjustments were not present