Add migrate.module support for uc_order (orders, order product details, etc)

After more testing, this appears good to go.

There's one minor complication handled by this patch, although I wish there was a cleaner solution for this. It's tied up with #610128: Can't add external and internal tables' columns to the same view which is still unresolved, and at this point, the best solution proposed there is a mysql-only hack. :( Here's the problem:

For the {uc_orders} record, we need delivery and billing versions of both the country and the zone. UC has its own magic integers for these things. However, the source data doesn't have those... generally, the source data is either going to have codes or names. UC has tables to map this stuff, but, since the tables live in Drupal DB, not the source DB you're migrating from, it's hard to make a view that has the UC-specific codes in the first place...

My "solution" is a bit of a hack. Instead of defining a single "country" field (which is really the country id), I define 4 fields: country_id, country_name, country_iso2, and country_iso3. There's help text saying "only define one of these depending on what you've got in your source data" more or less. Then in uc_order_migrate_import_uc_order() I've got some logic to map the values into the appropriate country code based on what field is defined... If we end up with a record that's trying to define the country twice (e.g. someone selected a source field for both country_id and country_name or something), we bail out with an error. It works, but it's a) a bit confusing in the UI and b) a bit ugly in the code.

I'd love the ability to define a field and then define some kind of "translation handler" for that field. In that case, we could still just have a single "country" field and "zone" field for either shipping or billing, but we'd let the admin select what kind of translation they want on that before it's stuffed into DB...

Anyway, migrate.module certainly doesn't support that now, and probably won't support it anytime soon, so I think what's in here is the best approach that doesn't require users doing a migration to replicate these translations themselves via hook_migrate_prepare_uc_order().

I've tested all of this and it's all working fine. Let me know if you have any questions.