chore: add columns and transformedData to ArtworkImport

[mzikherman]

I think this will allow Volt's table view of an import to be a bit generic, just showing the user the columns they initially included (and transformed/normalized data values).

Now, Volt still needs to 'know' for example that titles can have inline editing enabled and maybe should render differently than another column type, but I feel like that could be a little config within Volt: column names -> Component kinda thing. We can see if that makes sense to move somewhere upstream - into MP kinda like homeview. But, since Volt is likely to be the only client for this whole imports schema, we can probably keep that stuff in Volt.

Ultimately, we want the specifics of the CSV in question to 'inform' the Volt table rendering of the import. This is b/c different partners may start to include different columns, we have optional columns, etc.

We can even drive Volt's experience for images this way without a feature flag! If an import included image filenames as a column - it can present those and ask for the image upload step, as we currently do. But if an import didn't include that column...it won't render in the table and the UI can skip that step.

[jpotts244]

🫡

[Mitch-Henson]

This all looks good to me though I wanted to comment on a line that you wrote

If an import included image filenames as a column - it can present those and ask for the image upload step, as we currently do

I think that this is an assumption that needs to be validated by Anita as this is a business decision in my mind. That being said, we can still definitely take advantage of this logic and instead do only this validation in the backend, e.g. only reading from approved columns which can be feature flagged. This will hopefully make it a lot easier to separate the functionality as we can mostly limit it to a single API call

[mzikherman]

We can double-check for sure but no reason to gate the feature....if a CSV upload includes image filenames then we can unlock the advanced functionality.

[mzikherman]

This just came up in retro actually - we should lean on less flags the better (IMO) - and its ok to let something be 'discoverable' as well - but we can always double-check with Core.