Define method for obtaining a label.

I'm going to take it slowly so that you can see my thought process.

This is something that a carrier is "asked" to do, so the method ought to be defined on the Carrier superclass.  It is sensible to take method parameters exactly like `find_rates` for the sake of consistency.
In progress commit.

- Add a resource to UPS for the ShipConfirm feature.  This is only one of two resources required for generating a label.
- Move package node code to its own method because it is shared between label generation and rate requests.
- Enable support for Shipment/Shipper/Name element.  Use options to set this element's value.
- Build an XML document for ShipmentConfirmRequest.  Some of the elements are optional, as I'm following an example in the UPS docs instead of proceeding down the list of elements.  It will be necessary to decide how to support (or not) optional elements.
- Ensure the integration test sets the carrier to test mode.
Add payment information.

I only implemented one of several possible choices.  It happens to be the one I need, and I'm reluctant to dive into severely branch-like code at the moment.  I do plan on supporting all possible choices for this.

Search the July 2013 UPS Shipping Package XML Developers guide for "/ShipmentConfirmRequest/Shipment/PaymentInformation/" (page 92) if you want to see the reference I used.
Always give build_location_node an options hash.

It seems like this method should set the value instead of relying on the caller to not pass in a nil value.
Extend label integration test, get proper label.

The second phase (accept) is where the label image comes from.  To get the image, you use the digest from the first phase (confirm).  This let's you verify cost information and other such details presumably.

I still need to handle API validation errors and figure out how to expose the data retrieved from UPS.

Furthermore, the UPS API supports a variety of options for shipping that I must be sure to support in order for this to be useful to anyone other than me.
Add fixture data.

This fixture data was generated using CustomInk's integration test credentials.  It contains a response to the accept request and a response to the confirm request.
Make variable names more consistent.

label_request is ambiguous because it doesn't tell you which of the two phases it is intended for.  Yes, it is implied that it's the first step, but it's still kinda sloppy.
Change the scope of the integration test.

Generate labels for three packages instead of one.
Add more fixture data.

This fixture data now includes labels for three different packages.  Instead of replacing the single package shipment, I think it's going to be useful to have both once I dive into the unit tests.
Define LabelResponse class.

The class doesn't do anything yet.  Originally, I thought that there would be multiple labels returned by the obtain_shipping_labels method.  However, this doesn't conform well to what actually happens.  Although you obtain many labels at once, this counts as a single transaction.  As such, it makes sense to have on LabelResponse that has multiple individual (images) of labels.

The specifics of how this object provides data will be tested at the unit level.  I don't think it is appropriate for the carrier object to perform this mapping.
Define a LabelResponse class.

This contains tracking and label data.  Everything else seems irrelevant for now.

The label response needs its own tests.  Technically it's covered by the ups_test, but that's kinda stinky.  Once I figure out how to handle encoding the image, I'll probably add some tests.
Reorganize test.

- Add phone number to a piece of fixture data.  I'm going to assume that this is something that someone would pass anyhow, but that seems hasty too.
- Use location instead of options to obtain the company name, phone number, and attention name.
Support single label responses from UPS.

The XML parser seems to return varying structures depending on the number of child elements that are present.  If one exists, a hash is returned.  If many children exist, an array of hashes is returned.  This change creates a list from the hashes.
Use custom attr reader for labels data.

Extracting labels at initialize time is not the way to do it: this is not deserialization friendly.
Log more, provide more detail when things go awry.
Support Saturday delivery option.
Remove dead code for parsing label response.
Add new (missing) fixture data.
Support reference number.

This is minimal, and has pretty shoddy testing.
Make options consistent with UPS XML.