Feat/migrate block grid config

[ryan-woodruff]

Adds in some rough functionality to convert config and styles from the legacy grid to the BlockGrid & acts as a start for settings conversion. This implementation only handles the config/styles in the Layout layer (row) but perhaps similar implementations can be adopted for other layers.

It does this by:

Content Types

1. Reading config/styles & merging them (they have the same JSON data structure, afaik these are split up in the legacy grid for permissions based settings).
2. Create datatypes called BlockGridSettings_ for each grid.
3. Add the above block grid settings to each of the layouts for that grid. (It is safe to assume that all the layouts can have these as that is the behaviour of the legacy grid).

Nothing is done with modifier & prevalues as this is out of scope for me personally, but should definitely be included in a future update

Content Converts content by simply porting the string over or using a process defined by anything that implements IGridSettingsMigrator. This is tied to each "datatype" (view) using the ViewKey property. The process for the conversion is defined in ConvertContentString. I would have liked to make this more customisable, but this seems to do the job for now. The NewDataTypeAlias should already be created in Umbraco but perhaps a way to do this automatically based off of a description in the IGridSettingsMigrator could be done to make this more programmatic? The setting "content" migrator does hook into IContentTypeService & IDataTypeService which isn't great as that means it relies on the old data being present to work and goes against the idea of being able to go from old usync config -> new , on a fresh umbraco site/database.

Note: One thing I would have liked to not do is pass the dataTypeProperty.DataTypeAlias around (specifically to layoutSettingsBlockHelper.AddGridSettings() & layoutBlockHelper.AddLayoutBlocks() ). I was considering putting in into a context but then realised that probbaly wouldnt work and/or be messier as that would involve just passing it to there and storing it there, which is probably an equally as bad solution. I'm more than happy for alternatives to this.

Some more default GridViewPropertyMigrators will be needed (they may need more customisable interfaces?) for the following:

radiobuttonlist mediapicker imagepicker booleantreepicker treesource multivalues

[KevinJump]

Yes - this is a winner, if we can just work out a way of not using ContentService or Datatype service directly.

what information is needed with these two ?

As far as i can see we are using content service to find a property on the Contenttype ?

I think we do that is the context. with GetDataTypeAlias

https://github.com/Jumoo/uSyncMigrations/blob/main/uSync.Migrations/Context/ContentTypeMigrationContext.cs#L256-L258

this returns the DatatypeAlias for a given ContentType and property. so we do probably have the info already? (i could be reading this wrong?)