Moved Remove operation to start of Table.Apply

[rekhoff]

Description of Changes

Intends to resolve issue 343 of the C# SDK.

In issue 343, the example project uses fails due the PlayerFruitState table being defined with an Identity value is marked as unique rather than primary_key as is typically the case. Without defining a primary key, data from all rows is used as the primary key.

In the sample project, when the PlayerFruitState table was being updated, the Identity value would stay the same, and the other values would change. This should still be a supported operation, and would look like a removal of the Identity row with the old value and an addition of the Identity row with the new value, rather than a single update operation.
Note: If the Identity was marked as primary_key, this would be an update operation, because only the Identity value would be used for the key, rather than all rows.

Because of the existing order of operations in a Table.cs's Apply method, the new row being added to the PlayerFruitState table prior to the old row being removed. Due to the Identity value having the unique constraint, this caused the initial add to throw an error during the add operation.

This change simply moves the Remove operation before Add, which is best-practice for these types of operations.

API and ABI breaking changes

Not API breaking.

Expected complexity level and risk

1

Testing

• Tested against "FruitMerge3D" sample project

[jdetter]

I gave this a try using my fruit merge 3D example and it works now, thanks Ryan! 👍