Practical fixes and changes to state saving/restoring

[TETYYS]

I have put serialized state saving and restoring to practice and discovered a couple of things that I think need changing. The most important one is the ability to resolve FilteringDescriptorState value and values, with other less major fixes.

Resolve value and values in filtering descriptor state

Added tokens for which value and values can be restored, like it was done with other objects that are unknown to the library and are not recreateable by its own.

Expose parent objects to IDataGridStatePersistenceTokenProvider methods

Expose parent objects to IDataGridStatePersistenceTokenProvider methods to provide more information needed to resolve tokens. For example, if sorting is used with column definitions and DataGridTextColumnDefinition, a DataGridColumnValueAccessorComparer is automatically generated, which makes it hard to determine which column is bound to sort descriptor. Descriptors are now passed in most of the methods of IDataGridStatePersistenceTokenProvider, which also eliminates a need of tracking object instances of comparers or predicates in order to generate tokens out of them. Now, matching by ColumnKey is possible, as it is done the same in other places. Tests still have tracking by object instances done though, I did not see a need to redo it as it works.

Populate ColumnKey in resolved DataGridColumnDefinitions

This aligns DataGridColumnDefinitions more closely as they were before saving+restoring. They are still different, for example the filtering predicate will most likely originate from a different place compared to organic filtering descriptor.

With ColumnKeys now populated, check in CaptureAndRestoreSearchState_Resolves_Definition_Columns is changed to adjust for non-fallback behavior (DataGridColumnMetadata.GetDefinitionKey previously fell back to (object)definition)

ColumnId restoration to original form in FilteringDescriptor

As a side note, ColumnKey and ColumnId are used interchangibly in some places, and it is not really clear whether library users should put column instances, their definitions or string keys (most often in form of nameof(Xxx)). Filtering Model (End-to-End) instructs to use string keys, however they weren't really compatible with how calls to IDataGridStatePersistenceTokenProvider methods behaved, and it seems that most of the tests expect instances there.

I modified it to resolve DataGridColumn or DataGridColumnDefinition depending on what was there before state is saved with best effort fallbacks. There is no good way to tell which one we should restore after the state is saved though, so ColumnIdIsColumnDefinition is added to FilteringDescriptor

[TETYYS]

ci failing after build & test succeeds, likely related to ci itself

[wieslawsoltes]

ci failing after build & test succeeds, likely related to ci itself

Its issue with test results on CI, nothing related to this pR