Custom Fields: Local editing handling

[hafizrahman]

Part of: #13493

Please do not merge until target is trunk

Description

The flow for editing/adding/deleting custom fields can be described as follows:

1. Each item in the Custom Fields List screen can open the Custom Field Editor screen. In the editor, merchants can change things and then tap "Done" when they're done editing. Doing so will return them to the list screen and the change will be shown.
2. Merchant can also delete a field from its Custom Field Editor screen. This removes the field from the list screen.
3. Custom Fields List also has an add button that opens the editor, then merchant can also tap "Done" to keep the change. This adds a field to the list screen.
4. All changes from edit/delete/add actions above are still pending. The Custom Fields List has a "Save" button, which acts as the only way to do remote API call to save. It will save all existing changes at once, matching the behavior in core.

This PR handles the local editing behavior, by adding these:

1. CustomFieldsListViewModel which handles the business logic.
2. The viewmodel contains editedFields and addedFields to store the pending edit and addition. It also has combinedList which is an array of the latest combined changes. Depending on the remote call design, any of these can be used to do the call.
3. The viewmodel has editField() and addField() functions that can later be used when editing or adding a field.
4. Unit tests for the viewmodel.

Not in this PR and will be added separately:

1. Handling for deletion.
2. UI functionality for editing or adding field.
3. UI functionality for remote saving

Steps to reproduce

The handling is not used anywhere in the app yet, so for now just check the code and ensure the unit tests also passes.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on all devices (phone/tablet) and no regressions are added.

[dangermattic]

	1 Warning
⚠️	View files have been modified, but no screenshot or video is included in the pull request. Consider adding some for clarity.

Generated by 🚫 Danger

[wpmobilebot]

Version 20.4 has now entered code-freeze, so the milestone of this PR has been updated to 20.5.

[wpmobilebot]

Version 20.5 has now entered code-freeze, so the milestone of this PR has been updated to 20.6.

[hafizrahman]

Closing this in favor of #14029