refactor(config-handling)!: Complete rework of internal config parameter and sequence data handling

[Slider0007]

Complete rework of internal config parameter and sequence data handling

Main design goal: Single source of truth --> Only firmware is maintaining configuration parameter

1. Complete rework of firmware structure to use newly implemented parameter handling

• Implement centralized parameter structure which handles all relevant firmware parameter
• Implement a standardized REST API interface to interact with newly implemented parameter handling --> REST API config
• Implement parameter validation checks
• Implement a persistence procedure which persists the parameter set to SD card (config.json / JSON notation)
• Implement migration routines to migrate previous configuration parameter sets (config.ini + wlan.ini) starting firmware v15.0 and newer
• Migrate wlan.ini parameter to centralized structure to allow WLAN and / or IP configuration via WebUI
• Credentials are not accessible using any API or by browsing SD card (stored in NVS flash)
  --> To be on the save side, delete config_ini.bak and wlan_ini.bak backup files from SD folder /config/backup (only possible via direct access to SD card)
• Implement a WLAN configuration fallback scenario if persistent config file is missing/corrupted (reload last WLAN config from NVS to ensure at least device boot and WLAN connection to allow restoration of configuration, connection will be using DHCP service, static IP needs to be reconfigured)
• Rework of firmware packages (only 1 zip package is needed to handle all tasks: initial setup, remote configuration via AP and OTA updates. Newly introduced firmware packages can be used on firmware version v15.0 and newer, e.g. to update via OTA to latest firmware version)
• Device can even be booted without any configuration file persistent on SD card --> default configuration will be used, only WLAN config is mandatory to have access to WebUI

---

2. Rework of WebUI parts which handles any parameter. WebUI interacts now with firmware using a standardized REST API interface. Firmware finally handles all parameter related tasks. (No more parameter file writting triggerd by WebUI)

• Rework of all parameter related HTML pages to adapt to newly implemented REST API
• Complete rework of config handling page (only activated parameter are visible, no direct edit mode, no expert view switch: Expert parameter are still highlighted)
• Implement a delta loading to allow updating only parts of configuration via REST API

---

3. Implement a centralized struct to handle sequence related data

• Unify and simplifies data access
• Single source for all sequence related data

---

4. Further changes firmware

• Implement a new init state - time sync waiting state - (also shown in WebUI) and interlock timesync event with process start to ensure process start with synced time (can be overruled with new parameter: Process Start Interlock in Network > Time Synchronization section - default: Enabled)

• Refactor unity test to align with new parameter and sequence data handling

• Refactor of firmware component names

• Complete code review to remove unsed functions

• Refactor some function / variable namings (Still in progress...)

• Further smaller harmonization

• Further smaller cleanup

---

6. Further changes WebUI

• Refactor and harmonize HTML file namings
• Further smaller harmonization
• Further smaller cleanup

---

⚠️ NOTE 1: Migration is supported for firmware version 15.0 and newer (only GPIO parameter are not migrated).
⚠️ NOTE 2: OTA update from jomjol software is also possible (just ignore the warning of not matching filename), but migration is only supported partly (Uses default value for unknown and not migrated parameter; mainly camera related parameter)

---

Usage after based on ESP32:
RAM: [= ] 13.1% (used 42856 bytes from 327680 bytes)
Flash: [======== ] 81.4% (used 1583485 bytes from 1945600 bytes)