Re-use column instances for state persistence

[MayaKirova]

Is your feature request related to a problem? Please describe.

When restoring columns via the state persistence feature, there's the following limitation:
https://www.infragistics.com/products/ignite-ui-angular/angular/components/grid/state-persistence#restoring-columns
Which requires any complex objects and templates that were set on the columns to be set back on columnInit manually to get the same state as before.

This is not possible in other platforms like wc/react/blazor since the event emits the original angular column while the templating engines on those platforms work with different templates (lit, react, razor/lit templates) that cannot be set on the angular column directly. Hence restoring those is impossible.

More context and discussion on this can be found here: #13659

Describe the solution you'd like

In most cases the grid that you want to restore the state on is the same grid with the same columns, hence it already has an existing instance of each column available. When possible we can reuse the column that already exists on the grid and restore the state on it, instead of creating new column instances every time. This would remove the need to set any complex objects manually back on the column.

Describe alternatives you've considered

Having the events in the related platforms emit the correct objects for the related platform. For example the IgcColumn in WC, so that you can set the correct template type in the event. However this would need major changes, that would also be breaking. So we opted to remove the need to use the event in the first place for most state persistence scenarios.

Additional context

Note that this will not remove the need for the workaround completely, since columns don't have an unique identifier. We have chosen to treat the field property as a key for the columns (for column groups - a combination of the keys of the children), but there are instances where columns don't have any field set or have duplicate field. In those cases the limitation still stands since we cannot identify which column the previous state is intended for, hence you would still need to manage setting complex object on them yourself.