fix(runtime): make user-facing headers compile under gnu++14 (mbed cores)

[thiagoralves]

Summary

Backports incidental C++17 features out of the four strucpp runtime headers reachable from c_blocks_code.cpp's transitive include chain (iec_var.hpp, iec_string.hpp, iec_traits.hpp, iec_subrange.hpp).

User code in openplc-editor's Arduino flow compiles c_blocks_code.cpp under whatever `-std=` the platform's Arduino core picked. Every mbed-based Arduino core — `mbed_nano` (Nano RP2040 Connect, Nano 33 BLE), `mbed_opta` (Opta), `mbed_giga` (GIGA), `mbed_portenta`, `mbed_edge` — hard-codes `-std=gnu++14` in its `cxxflags.txt`. On those targets every C/C++ POU compile was failing with cascading `'is_convertible_v' is not a member of 'std'` / `'auto' parameter not permitted in this context` errors out of these headers.

What changed

Purely syntactic; no semantic change:

• `iec_var.hpp`: 8× `std::is_X_v` → `std::is_X::value`
• `iec_string.hpp`: 3× `std::is_X_v` → `std::is_X::value`; `TO_STRING(integral)` rewritten from `if constexpr` (C++17) into two SFINAE'd overloads (signed/unsigned), same behaviour
• `iec_traits.hpp`: 3× `_v` substitutions; 2× `std::bool_constant` → `std::integral_constant<bool, X>`; 4× `template<typename B, auto L, auto U>` → typed `template<typename B, B L, B U>`; 14× `inline constexpr` variable templates → `constexpr` (inline variables are C++17; variable templates without `inline` are C++14)
• `iec_subrange.hpp`: primary `IEC_SUBRANGE_Value` / `IEC_SUBRANGE_Var` template heads + `IEC_SUBRANGE` alias switched from `auto Lower, auto Upper` to `BaseType Lower, BaseType Upper` to match the forward decls in `iec_traits.hpp` and stay consistent

The precompile stage in openplc-editor / openplc-web continues to use `-std=gnu++17` and the strucpp runtime CMake test suite still requires C++17 — nothing in this PR downgrades the strucpp project's own toolchain.

Test plan

• Compile a c_blocks_code.cpp-equivalent TU under `-std=gnu++14`: passes (was failing on every mbed-cored Arduino board)
• Compile the same TU under `-std=gnu++17`: passes (the previously-working AVR / rp2040 path)
• Both compiles produce byte-identical 2552-byte `.o` files → same ABI under either standard
• End-to-end test on openplc-editor with patched headers: Nano RP2040 Connect project with a C/C++ Function Block compiles cleanly (user-verified)