Schema fix MJ-385

I noticed last week that our data model was not in line with the HR-XML/OAGIS spec we've chosen to support. These changes bring us into compliance with that standard.

An excerpt from the schema for an address in the [HR-XML/OAGIS standard](http://www.schemacentral.com/sc/oagis941/t-ns1_AddressBaseType.html):

    Choice [1..1]
        AddressLine [0..*]    
        Sequence [1..1]
            LineOne [0..1]    
            LineTwo [0..1]    
            LineThree [0..1]    
            LineFour [0..1]    
            LineFive [0..1]    
        Sequence [1..1]
            BuildingNumber [0..1]    The Number of the building or house on the street that identifies where to deliver mail. For example, Building 300 on Standards Parkway
            BuildingName [0..1]    The building or house name on the street that identifies where to deliver mail
            StreetName [0..1]    The Street Name where the building/ house is located
            Unit [0..1]    Identifies the apartment number or office suite.
            Floor [0..1]    The floor where the housename is located
            PostOfficeBox [0..1]    Identifies a Post Office Box number
            DeliveryPointCode [0..*]    Identifies the Dock or the Mail Stop or Lane or any other specific Delivery Point.

Our current schema is mixing options 2 and 3—this is invalid. Options 1 and 2 are  straightforward and map closely to how we fill out an address. If we receive any information in the third format, the fields can be concatenated and placed in address_line_one.

The updated schema:
- makes all columns optional. Because we're not mailing these people packages, we don't need a complete address (or an address at all, but that's a different story). If someone just wants to put in their country, or city/state, they can do that.
- no longer requires a label; there's no need to increase mental overhead for the user with an extra field they have to fill out (and think of a name, too!).
- changes the U.S.-specific "Zip Code" to the more universal "Postal Code"
- removes the Unit and Post Office Box columns. The address line one and address line two will handle all cases of the former (without adding the confusion of what to put into the unit/p.o field)

I've appended the vestigial data to the address_line_one field for the few addresses in the database with a P.O. Box or Unit field; the migration can now be run on production.

All tests pass.