FIO-9385 Preserve non-default widget settings after evaluating field logic

[blakekrammes]

• originalComponent in Component.js did not capture non-default widget settings since they were added after component initialization
• During field logic evaluation, the component was falling back to originalComponent and not preserving the widget settings
• Update originalComponent after applying widget settings in TextField and DateTime to maintain them after field logic eval

Link to Jira Ticket

https://formio.atlassian.net/browse/FIO-9385

Description

What changed?

Set this.originalComponent in the DateTime and TextField components. Since this.originalComponent was only being set when the component was initialized and the non-default widget settings are applied after, none of those widget settings were preserved after field logic was evaluated (see here) due to this.originalComponent being used to update this.component after evaluation.

Since the non-default widget settings were not preserved after evaluating field logic, this.settings.readOnly was not present in CalendarWidget when setting the value, which for some reason caused the wrong timezone to display in the DateTime component (see Jira ticket).

Why have you chosen this solution?

I wanted to fix the bug closer to the source of the issue. It seems that in the case of DateTime and TextField components, no non-default widget settings were being applied to this.originalComponent such that any non-default widget settings would be wiped after evaluating field logic. The original bug report didn't touch on TextFields, but I wanted to address any potential bugs there as well.

Breaking Changes / Backwards Compatibility

n/a

Dependencies

n/a

How has this PR been tested?

Automated and manual testing.

Checklist:

• I have completed the above PR template
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (if applicable)
• My changes generate no new warnings
• My changes include tests that prove my fix is effective (or that my feature works as intended)
• New and existing unit/integration tests pass locally with my changes
• Any dependent changes have corresponding PRs that are listed above