feat(runtime): add read-through proxies on IECStringVar / IECWStringVar

[thiagoralves]

Summary

Without these proxies, user code reading a STRING / WSTRING pin has to write name.get().c_str() / name.get().length() / name.get()[i] for every read — IECStringVar would otherwise expose nothing but get() / set() / operator= to its consumers.

Add length(), c_str(), and operator[] (read-only — returns char / char16_t by value) on both IECStringVar<MaxLen> and IECWStringVar<MaxLen>, routed through the force-aware value (forced_value_ when forcing is active, value_ otherwise). This mirrors how IECVar<T>::operator T() already exposes the underlying numeric for force-respecting reads on numeric pins.

Why comparison operators are NOT proxied

operator== / operator!= are intentionally left off the wrapper. The free-function overloads at the bottom of each header already cover every cross-class compare path:

inline bool operator==(const IECString<L1>& a, const IECStringVar<L2>& b)
inline bool operator==(const IECStringVar<L1>& a, const IECString<L2>& b)
inline bool operator==(const IECStringVar<L1>& a, const IECStringVar<L2>& b)
inline bool operator==(const IECStringVar<L1>& a, const char* b)
// + converse / IECVar wrappers

Adding member operators on IECStringVar would risk overload ambiguity at ST call sites that currently bind to the free functions.

Unlocks

• openplc-editor PR #831 (c_blocks STRING/WSTRING standardization) — user C/C++ POU bodies can now read pins via plain name.length() / name.c_str() / name[i].
• The matching openplc-web mirror PR will follow once this is released as v0.5.1.

Test plan

• npm run build succeeds.
• Integration tests pass: npx vitest run tests/integration/st-validation.test.ts → 64/64 green.
• Reviewer: verify the integration test suite still passes in CI.
• Reviewer: confirm no diagnostic on iec_string.hpp / iec_wstring.hpp introduces an unintended overload (the design rationale for omitting ==/!= proxies is documented in the source comments).

🤖 Generated with Claude Code