Fix crashing when attempting to lock shared memory in debug build

[Sainan]

This is a bandaid at best.

• Ideally, this outdated "shared_memory" crate version should be avoided since even its author is now heavily backpedalling on this.
• Probably the virtual control executable should be bundled with the SDK, so one doesn't have to compile it themselves and then run into these issues.

In any case, previously using cargo build to get the wooting-analog-virtual-control.exe would have the executable crash/panic on start, now it doesn't anymore. The plugin had the same issue when compiled in the debug configuration.

And the device_id field was unused anyway.

[simon-wh]

• Ideally, this outdated "shared_memory" crate version should be avoided since even its author is now heavily backpedalling on this.
• Probably the virtual control executable should be bundled with the SDK, so one doesn't have to compile it themselves and then run into these issues.

Agree on the first point, I'm not a massive fan of the way it's set-up.

For second point, I somewhat feel like maybe this whole thing shouldn't necessarily exist in the first place?

[Sainan]

I think the test plugin is still useful for developers without an analogue keyboard of their own, it's just a matter of making sure they're able to actually use it without problems.

[simon-wh]

True, it is a helpful tool for that purpose, which is why I created it in the first place. However, I feel like currently it opens up some doors for input automation in games which I'm not sure if game devs would be super happy about 😬 (but maybe test-plugin or not doesn't really change that story)

Either way, I'll merge this PR as this discussion is somewhat unrelated to the changes themselves

[Sainan]

As long as there is a plugin system without some sort of approval process (and verified e.g. via digital signatures), it's always gonna be possible to 'abuse' the analogue SDK for input automation. I doubt that's a huge concern right now, tho.