Improve Windows Update Completion Handling with Extended Validation and Optional Reboot Delay

[hendrie6]

Description:
This pull request adds additional safeguards to handle scenarios where Windows Updates successfully complete but the worker process does not exit as expected.

Issues resolved:
This addresses multiple issues that are opened related to TiWorker 'hanging' (#147 #49 #91).

Code added:
To address this, I’ve introduced extended validation logic that more reliably determines update completion by inspecting:

• Windows Event Logs
• Windows CBS logs

This functionality is controlled via a new optional flag:
use_extended_validation — when enabled, the worker uses log-based validation to confirm update status rather than relying solely on process behavior.

In addition, this PR adds:
reboot_delay — a configurable delay (in seconds) that pauses execution after updates complete when a reboot is required. This allows systems additional time to settle before the workflow proceeds. I mainly use this when testing the process and needing it to pause while I troubleshoot before a forced reboot.

These changes aim to improve reliability in edge cases while remaining fully backward-compatible and are opt-in.

Thanks for reviewing — feedback is very welcome!

[hendrie6]

Adding RebootDelay and UseExtendedValidation parameters. Not specifying them results in the same current functionality.

Specifying a reboot delay in seconds delays the reboot after successful installation where a reboot is required. Mainly to help with troubleshooting purposes.

Setting UseExtendedValidation to true results in extending the monitoring of the Windows update installation status based on event logs and CBS logs. I've found this to resolve issues where TIWorker.exe doesn't exit after completing an installation, resulting in this module looping while it waits for TIWorker.exe to exit even though the update has already installed.