Field language properties renamed to langcode

As part of our bigger effort to clean up our API in terms of where do you encounter language (a language object) or langcode (the identifier of a language), we modified the internal storage and as a consequence the applicable exposed parts of the field API to refer to langcode.

The main change in SQL storage is in field_sql_storage_update_8000 - that entity data and revision tables now use 'langcode' instead of 'language' as column names.

Many hooks and functions such as hook_field_language_alter(), hook_field_available_languages_alter(), etc. got their arguments renamed from language to langcode and languages to langcodes respectively. This should not affect code invoking them at all. (as they already worked with langcodes but were improperly named) Also, EntityFieldQuery's fieldCondition(), fieldLanguageCondition() and addFieldCondition() abstract language handling, but internally language_group was changed to langcode_group.

Finally, although the field attach functions abstract those from direct use, the utility functions _field_invoke_multiple(), _field_invoke_multiple_default(), _field_invoke() and _field_invoke_default() got their $options['language'] argument renamed to $options['langcode'] as well. If you use these functions directly, take note of these changes.