Unify 'name' / 'field_name' in FieldConfig / FieldStorageConfig

Problem/Motivation

The property that holds the field name is different in FieldStorageConfig ('name') and FieldConfig ('field_name').

That somewhat made sense when we had FieldConfig / FieldInstanceConfig, since the FieldConfig was the "primary" entity (thus it had a 'name'), and FieldInstanceConfigs were secondary entities, referring to a FieldConfig by [entity type + "name of the FieldConfig", i.e 'field_name'].

Now that FieldConfig / FieldStorageConfig are aligned with the more generic concepts in the Entity Field API, the question of "who holds the 'name', who refers to it" shifted a little.

- If we keep the current logic, then the current 'field_name' in FC is wrong, it should be 'field_storage_name', but that feels off because:
- In the Entity Field API, the FieldDefinition is the primary concept. Thus doesn't really make sense that the FSC is the one that holds the "name". We won't change everyone's language habits to say "field storage name" instead of "field name".

Proposed resolution

In the FieldConfig / FieldStorageConfig world, I think it's clearer to view things as "the FC and FSC are related by referring to a common 'field_name'". In other words, neither holds the name, they both refer to a 'field_name'.

--> Use 'field_name' in both FC and FSC
I.e rename 'name' to 'field_name' in FSC

Remaining tasks

Agree, code, review...

User interface changes

None

API changes

- A config entry changes in field.storage.*.yml (thus, according to the beta guidelines, is a schema change that should happen before beta...)
- The corresponding runtime property changes in FieldStorageConfig objects. This should only affect code that creates and interacts with configurable fields specifically, not using FieldStorageDefinitionInterface - that is, probably very little actual runtime code, but a fair amount of tests...