[META] Finialise i18n issues

Currently this is the complete list of issue related to i18n and they fairly much hit all sections of the module in some way. As attisan puts it:

this module IS very useful - as long as one isn't using a multilingual webpage

Field display / Core list translation / Core properties
#1415284: Countries in profile select-list not translated

Attached Fields
#1660370: Countries is not integrating properly with Entity Translation

Importing
#1812384: load translated country names into i18n
#1830198: Better support for various providers of Country data.

Views
#1803548: Countries views field "name" does not work with countries_i18n

Misc
#1891106: country field: content language VS interface language

So an i18n newbie's take...

Initiation and updates

Most country names will default to the current language that the module was enabled on as the module uses Drupal's internal list to specify the names. The official name will most likely be in English.

Support for t() during the import was added with #1490864: Multilingual Support in field_formatter, April 6, 2013, so all names will potentially be imported in the correct language. That is if "correct" is read as the language that the site was in when the module was installed.

Task One
Update names on install from the csv file. Done as per some per comms suggested that this was best and to make task 2 possible.

The core function, _country_get_predefined_list(), uses a static cache for the translated strings making a language change impossible. :/

Task Two (storage)
Translate all country entities in the default site language in the db and record what that language was.

Task Three (updates)
Going with the KISS, db is updated to the sites default language.

Task Four (imports)
Translated to the default language during updates.

Translatable properties

The name property should be translated if countries_i18n is enabled as of #1609150: Support entity label (and callback) (June 30, 2012) and #1889998: Use label callback instead of name property (April 6, 2013). This has been refactored to provide contextual i18n translations.

Task Five
Use a single point of handling properties. Without defining a custom entity per say, this has been assigned to the function country_property() function.

API Change

- function country_property($country, $property, $default = NULL, $sanitize = TRUE)
+ function country_property($country, $property = 'name', $options = array())

There is a wrapper to parse parameters that use the 7.x-1.1 format.

Direct use of countries_t() and $country->label() is depreciated in favor of country_property(). $country->label() was depreciated as there was no apparent entity language context for any specific request.

Lots of changes here to chain the content language down where applicable.

• $item['safe_value'] is the countries name in the entities language. Only used as a formatter fallback internally.
• country_property() and entity language is used on all core formatters. If not set, $language_content is used.[Maybe will fallback to $language here?]
• countries_get_countries() now accepts a langcode parameter and defaults to the global interface language.
• The country FAPI element now accepts a language parameter albeit not used internally.
• Diff integration converted this this
• No widget translations. There is no context given in the options callback, so this is also left out of the country/continent widget. I think that this is the norm anyway ;)
• countries_t() will only trigger countries_i18n_translate() if the db language does not match the requested language.
• countries_get_continents() et al all accept language arguments
• New views field handler