Fix #739: allow editing ByteString values when writing a node

[romanett]

Proposed changes

When writing a node whose value is a ByteString/byte array in the UA Sample Client, the value editor did not let the user modify the bytes. GuiUtils.EditValue had no BuiltInType.ByteString case, so a ByteString fell through to the read-only ComplexValueEditDlg where DataListCtrl renders the bytes as 16-byte blocks and disables the Edit action.

This change adds a dedicated BuiltInType.ByteString case to GuiUtils.EditValue (in Samples/ClientControls.Net4/Configuration/Common (OLD)/GuiUtils.cs). It renders the current bytes as a space-separated hex string, opens the existing StringValueEditDlg for editing, and parses the edited text back into a byte[].

Parsing is lenient: ParseByteString accepts hex with optional 0x prefixes, commas, dashes, and whitespace (so both 0A 1B 2C and 0x0A,0x0B work), and falls back to base64 when the input is not valid hex. Invalid input raises a clear FormatException describing the accepted formats. Reusing StringValueEditDlg keeps the change small and avoids a new dialog.

Related Issues

• Fixes UA Sample Client: cannot edit a byte array (ByteString) when writing a node #739

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• Enhancement (non-breaking change which adds functionality)
• Test enhancement (non-breaking change to increase test coverage)
• Breaking change (fix or feature that would cause existing functionality to not work as expected, requires version increase of Nuget packages)
• Documentation Update (if none of the other choices apply)

Checklist

• I have read the CONTRIBUTING doc.
• I have signed the CLA.
• I ran tests locally with my changes, all passed.
• I fixed all failing tests in the CI pipelines.
• I fixed all introduced issues with CodeQL and LGTM.
• I have added tests that prove my fix is effective or that my feature works and increased code coverage.
• I have added necessary documentation (if appropriate).
• Any dependent changes have been merged and published in downstream modules.

Further comments

The client sample project builds successfully with the change (only pre-existing warnings remain). This is a WinForms sample control with no automated UI test coverage, so the fix was validated by building and by reasoning through the edit/parse round-trip.