Update overkiz Atlantic Water Heater away mode switching

[ALERTua]

Breaking change

Proposed change

Based on #114184, changes the way the away mode is switched on for the Atlantic Water Heaters, setting setAbsenceStartDate and setAbsenceEndDate before switching on the away mode.
Alas, the initial functionality with just switching the away mode on has some kind of rechecks on the Cozytouch server, and the away mode keeps getting switched off on the server side due to the start and end dates being incorrect (past dates). This change corrects this behavior, making the switch consistent with the Cozytouch mobile application behavior.
The API uses two different away mode states: on and prog, but based on @sippe2 testing, those states have the exact functionality, so for the sake of consistency within the HA code, the on state is left to be used. This behavior may be changed if core maintainers wish so.
Here are @sippe2 tests for on and prog away modes:

Image tl;dr: on and prog are the same, setAbsenceStartDate needs to be set beforehand with now or the future, setAbsenceEndDate needs to be set beforehand and to be in the future, only then on or prog away modes may be set.
The way the API accepts setting dates is based on the original core:DateTimeState state for the DHW that returns a dict (like this {'day': 11, 'hour': 21, 'minute': 12, 'month': 7, 'second': 53, 'weekday': 3, 'year': 2024}), the dict is then passed as a start date, and then as an end date, but with year incremented by 1. The weekday seems to have no effect, and I didn't want to calculate the future date correct week day, but I can base all the dates on homeassistant dt_util and form those dictionaries from scratch based on datetime.now() and datetime.timedelta into the future if core maintainers wish so.
In my recent tests I discovered that core:DateTimeState device state does NOT have a consistent current datetime. I have found that the datetime gets lost after power outages, so in order to correctly set away start and end dates, the setDateTime command should be called to set the core:DateTimeState state of the device to the current datetime before setting the away start and end dates.
Also, changes the way to determine that the away mode is turned on by checking that the value is on or prog, which is consistent with the API and the mobile application.
Also, the commands executor now accepts an optional argument refresh_afterwards, that allows sending multiple commands without refreshing after each one, and then finally refreshing afterward. This fixes the device briefly going 'unavailable' when sending multiple commands as in switching the away mode on.

Uses the new Overkiz API fields. Related PRs:
iMicknl/python-overkiz-api#1293
iMicknl/python-overkiz-api#1294
If you are reading this while there are the hardcoded command names, I will update them to the pyoverkiz fields as soon as the PR above is released.
The code was tested on Atlantic Steatite Cube WI-FI VM 150 S4CS 2400W.

The ongoing plan for this PR:

• pyoverkiz constants PR gets merged Atlantic DHW setAbsense fields iMicknl/python-overkiz-api#1293
• pyoverkiz constants PR gets merged Add setDateTime command constant iMicknl/python-overkiz-api#1294
• pyoverkiz 1.13.14 gets into ha_core requirements via Bump pyOverkiz to 1.13.14 #122691
• This PR gets updated with the code that relies on 1.13.14
• This PR gets updated with the latest dev branch, gets its final tests, and switches to the non-draft mode
• Suggestions, fixes, retests
• This PR is approved
• This PR is merged
• This PR is released

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue: Add overkiz heating status, absence mode, and boost mode binary sensors for Atlantic Water Heater #114184
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hey there @iMicknl, @vlebourl, @tetienne, @nyroDev, @Tronix117, mind taking a look at this pull request as it has been labeled with an integration (overkiz) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of overkiz can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign overkiz Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[iMicknl]

Thanks again for your contribution! Some initial questions.

[eliasto]

Hi! Sorry to be bothering, I see the PR was approved last month, is it ready to be merged? :)

[emontnemery]

@ALERTua There's a merge conflict, can you fix it?

[ALERTua]

@ALERTua There's a merge conflict, can you fix it?

done

[frenck]

Thanks, @ALERTua 👍

../Frenck