Fix "Trace selection" index input inconsistency on Windows (Issue #111)

[okashaluai]

This PR resolves Issue #111 , which describes an inconsistent behavior in the "Trace selection" panel on Windows.

Problem:
On Linux, entering a number (e.g. 5) into the "Index" field correctly switches to the corresponding trace/sweep.

On Windows (Stimfit-Lite), entering a number sometimes causes the field to jump to a different trace than intended — making the input unreliable and confusing (What I have discovered is that the issue is simpler than expected the inconsistency is only with the index displayed and it has nothing to do with the showed graph -it shows the correct trace graph-).

Fix:
The fix included the following minor changes:

1. wxWidgets uses a predefined range of ID values internally, and we must avoid collisions with them. so I changed the IDs to start from wxID_HIGHEST + 1 and so on (wxID_HIGHEST is the last reserved ID).
2. The responsible wxSpinCtrl includes a wxTextCtrl for manual number entry. When a user types a number and presses Enter, that event: is ignored by default (goes to the default dialog handler and does nothing useful) unless you specify wxTE_PROCESS_ENTER

Prevented race conditions or unintended updates during input validation or focus events that were specific to the Windows build.

Tested on:
✅ Windows 10 with wxWidgets 3.2.8
✅Ubuntu 24

Manually tested input behavior for multiple sweep numbers — all updated correctly and matched expectations.

Notes:

1. The fix preserves existing functionality on Linux.
2. No changes were made to the core trace selection logic; only the Windows-specific input behavior was corrected.