Not able to configure OSDP constants

[adaskar]

** Is your feature request related to a problem? Please describe. **
Currently, all OSDP protocol constants (timeouts, retry limits, etc.) are hardcoded in
src/osdp_config.h.in
This makes it difficult for users to tune OSDP behavior for their specific use cases without modifying source files. For example, users who need faster response times for low-latency applications or those testing with reduced retry timeouts must edit the source code directly, which complicates updates and maintenance.

** Describe the solution you'd like **

Make all OSDP configuration constants configurable (ones which are not enforced by OSDP specification) at build time through both CMake and the lean build system (configure.sh), while maintaining backward compatibility with existing builds.

The solution should:

Allow users to configure values via CMake command-line arguments (e.g., -DOSDP_ONLINE_RETRY_WAIT_MAX_MS=3000)
Allow users to configure values via configure.sh options (e.g., --osdp-online-retry-wait-max-ms 3000)
Maintain all current default values for backward compatibility

[sidcha]

Hi, the reason config.h is generated during the build process from the template file config.h.in is so each user can freely configure the contents of the file as the like.

Allowing each of those to be configured the way you do in PR #265 will lead to a maintenance problem. If we really need to allow users to configure each value, adopting something like kconfig is a better approach.

[adaskar]

Hi,
In my opinion, it is not logical to edit a file solely to configure build time constants, as this is already addressed by the existing PR.
Furthermore, I find it inefficient to write the same constants in separate locations, which is precisely what my PR is doing now which is also looking bad.
Therefore, I propose that we consider moving all changeable constants into a separate header file using the #ifdef pattern.
Please share your thoughts on which approach we should adopt.

[sidcha]

Like I said earlier, the perfect solution for this situation is kconfig. Since I would have to do this anyway to support Zephyr apps naively, we might as well switch to that approach once and for all.