public.json: Add /orders and /order/{id}

I've simplified our existing Order model for the JSON API.  Changes:

* Simplified the status values, since customers are unlikely to care
  about the distinction between 'picking', 'picked', and 'shipped'.
  Maybe they'll care about 'verified', or maybe we'll want a
  'declined' status.  Or maybe that's just 'placed' with a trip that's
  already departed.  We can add more details here once we have a
  clearer picture of what we need.

  I've also added a 'lost' status, to account for orders that were
  placed and shipped, but then lost before delivery (e.g. in truck
  accidents).  That way everyone can keep track of the lost and
  replacement orders explicitly, which should cut down on confusion.
* Dropped 'checkout_payment_type', since referencing an external model
  seems like overkill here.  We may want to add some form of this
  (maybe an enum?) once we start implementing checkout.
* Dropped 'has_applied_debit', since that's business logic that
  doesn't need to be exposed directly.
* Dropped 'invoice_date' and 'order_date'.  I don't see why we need
  these.  The trip-cutoff is close enough for truck orders.  We'll
  likely need something special for UPS orders, but we'll likely also
  want tracking info and such for those too.
* Dropped 'origin'.  Who cares if an order was placed by a customer or
  by customer service?  What we should care about is the ID of the
  person who placed the order.  We should be able to get that from
  internal logs, but we may want to add a 'placed-by' field here in
  the future.  In any case, that information is likely to be for
  internal-use only.
* Dropped 'price_level'.  I don't think users are switching price
  levels so frequently that we need to record this on a per-order
  level.  We *do* want to record the invoiced price for each
  order-line, but we don't need to be able to re-create how we got to
  that price.
* Dropped 'post_shipped_invoiced_total'.  We'll want somewhere to
  record auxiliary charges (shipping, tax?), but I see no reason to
  mix that into the order-line costs.
* Dropped 'is_completely_on_the_fly'.  I don't think we need to record
  this distinction, which should just be an ephemeral workshop
  workflow issue.
public.json: Add /order-lines and /order-line/{id}

I've simplified our existing OrderLine model for the JSON API.
Changes:

* Dropped 'line_sequence_number'.  I suppose it's possible that folks
  would care about this, but I'm not sure its important enough to be
  worth a separate field in the API.
* Replaced 'average_landed_weight_at_checkout_time' and 'line_weight'
  with 'weight', which records the total picked weight for the line.
  The old fields just recorded the generic weights, not the actual
  picked weights.
* Dropped 'line_volume'.  Volumes are interesting on a per-trip level
  for allocating trucks and on a per-order/piece level for packing
  boxes.  Neither one of those is a per-order-line level.
* Dropped assorted cached fields.  We can add them back if follow-up
  requests turn out to be too slow.