Implement "migrationActions" to allow migration of data / data conversions between syncActions updates

Hi,
wouldn't it be awesome if we could update custom types or product types field definitions with a migration strategy to prevent data loss? As far I know, It doesn't exist any assistant in migrating, for example, a [`ProductVariant`](https://docs.commercetools.com/http-api-projects-products.html#productvariant) attribute between different field [`types`](https://docs.commercetools.com/http-api-projects-types#fieldtype).

**Scope**:

It will affect custom field definitions (`Types`, `ProductTypes`). That means migration support for `product attributes`, `custom attributes` of all supported resources. For the base fields, it's not necessary since the type will never change.

**Use cases:**

- A user might want to change the field `String` to `LocalizedString`
- A user might want to change the field `String` to `Number`
- A user might want to change the field `String` to `SetOfStrings`

With `migrationActions` I think about a companion to control how the old data is preserved.

That feature request comes from the daily practice experience with CT. Our product is very new and the model is constantly evolving.

I think this feature would bring a lot of value to the platform because it allows writing migrations scripts in a convenient and safe way.

That migration tool can be implemented in a very generic way so we don't need to respect every resource type individually.

It would require that "syncActions" can handle changes in custom attributes. I have seen that the current implementation respects only base fields or the implementation is just not complete.

**Out of scope:**

Updates in base fields are covered by `sync-actions` whereby the implementation doesn't cover all cases e.g there is no support for `custom fields` in types or product-types. That `half` complete implementation is really hard to track.

It's also really hard to find out what `sync` really means in the context of the "resourceType". As a customer, I would expect that sync checks EVERYTHING or at least the documentation should clarify the exact behavior.

**Related issues:**

https://github.com/commercetools/nodejs/issues/355

## Some code to illustrate the migration approach:

### 1. Determine attribute changes
```js
import { typeConversionMap } from '@commercetools/migration-actions';

const updateActions = productTypeSync.buildActions(next, previous, { preservePreviousFields: true });

// for example the attribute type has changed from "String" to "Number"
// we will create a new field to hold the new value + saving type and name differences in the attribute name

updateActions = [
{
action: 'addAttributeDefinition',
attribute: {
name: 'previous-attribute-name__string-number__next-attribute-name',
type: { name: 'Number' }
}
}
];
```

### 2. Apply changes and create temporary fields to hold the new value + conversion information
```js
client.execute(updates);
```
### 3. Fetch records which should be migrated
```js
// for example
const productA = {
attributes: [
{ name: 'previous-attribute-name__string-number__next-attribute-name', value: null },
{ name: 'previous-attribute-name', value: '2' }
]
};
```

### 4. We will create actions to migrate all fields
With the convention "old__string-number__new" or even "old__oldType-newType__old" we know how to convert that field.
```js
const typeConversionHelper = {
[[typeConversionMap.String][typeConversionMap.Number]]: old => parseInt(old),
[[typeConversionMap.String][typeConversionMap.ListString]]: old => [old.toString()],
[[typeConversionMap.String][typeConversionMap.LocalizedString]]: old => { en: old }
};
const dataActions = migrationSync.buildActions([productA], { conversionHelper });

dataActions = {
url: 'https://api/products/....',
body: {
actions: [
{
action: 'setAttribute',
name: 'previous-attribute-name__string-number__next-attribute-name',
value: 2
}
]
}
};
```
### 5. Determine changes based on the naming convention and remove old fields and rename temporary fields
```js
const dataActions = migrationSync.migrationCleanActions([productA]);

dataActions = [
{
action: 'removeAttributeDefinition',
name: 'previous-attribute-name'
},
{
action: 'changeAttributeName',
attributeName: 'previous-attribute-name__string-number__next-attribute-name',
newAttributeName: 'next-attribute-name'
}
];
```

La issue non indica file del repository, test o un punto di ingresso esistente per la migrazione. Inizia individuando l’implementazione di syncActions e la issue correlata #355, quindi determina come vengono gestiti attualmente i campi personalizzati e gli attributi dei prodotti. L’attività sarebbe completata quando saranno disponibili un design di migrazione concordato, il comportamento di conversione, le azioni di pulizia e la copertura per i tipi di risorse supportati.

Scritto dal modello di indicizzazione a partire dal testo della issue.