Converted Field API to CMI

• hook_field_config_info() has been expanded with a new label_callback to support the more complex label structure of field instances.
• hook_field_config_info() can now take an array for the name_key property, if multiple properties make up the unique name for a config file (such as fields and field instances).
• Field deletion previously supported multiple fields with the same name in the database at the same time. This has been removed as we no longer have numeric IDs per field and it would break the config management paradigm. Instead, fields must be fully deleted before creating another field with the same name. To help this along and to inconvenience the user less, fields are now immediately cleaned up upon deletion if they don't have any data (previously it required a cron run to really remove the field).
• The $field array returned by field_info_field() preivously had a property for $field['id'] that was a numeric ID. This is removed and the only identifier is the already existing $field['field_name'].
• field_info_field_by_ids() is removed.
• Fields previously supported updating their foreign keys and indexes through field_update_field(). This had been a requirement when field storage systems were swappable. Because we only support field_sql_storage (which will likely be merged back into field.module), supporting this was unnecessary for Backdrop. Indexes and schemas can be modified through db_add_index() and hook_schema_alter() if necessary. Field module no longer stores schema information in configuration.
• Image module previously stored a file numeric "FID" when setting the default value for a field. Because numeric IDs break the config migration between environments, we now store the file URI directly without an associated file entity.

So other than the elimination of auto-increment IDs in the system, we have a highly compatible system. Unfortunately, the directness of the mapping results in a lot of config files. To manage a field, 3 files are required:

• The global field configuration file.
• The bundle instance configuration file.
• The bundle settings configuration file.

Long-term, I'd love to see the instance files and the bundle settings file merged into the entity bundle file for each type (e.g. the node.type.article.json or taxonomy.vocabulary.tags.json files). But for our first pass at this support, combining the storage of these different settings would mean we'd have to read the files multiple times (e.g. both in node_get_node_types() and in field_info_instances()). We'd need a more generic entity-level management structure in order to handle combining these configurations together.

Another goal we should pursue, and sooner, is the ability to export an entire content type all at once. Right now you can export a content type, but its fields are all separate configurations. You have to export the type, then the fields, then the instances, then the bundle settings. This isn't practical, so the only way to move a content type is probably going to be a full site export (or managing it through Git). I'll file a separate issue for solving this problem.