Add an initial store model

The attributes are all the ones that will be supported for the initial
preferences-onto-store refactoring

Related to #4415
Create a store on new/store migration

Grabbed the defaults from the existing preferences.

Related to #4415
Switch config editor to modify Spree::Store

Related to #4415
Switch examples off of site_name

With site_name now on store, we need to track something so it may as
well be track_inventory_level as an example

Related to #4415
Switch app config test to move off of site_name

Related to #4415
Switch Spree::Config to use new store attributes

Related to #4415
don't override existing configuration methods

Related to #4415
meta_keywords delegated to description
Updating for new preferences api

Broken by @jhawthorn's a36381edb9014a97c7d337cb1d85989672388428

Related to #4415
add searching and paging for admin promotions area

Fixes #4478
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
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