Support storing and applying of memory content

[martin-fleck-at]

What it does

Add commands to store and apply memory content as Intel HEX file

• Encapsulate behavior in new MemoryStorage class
• Trigger 'store' from Memory view, Variables view and command palette
• Trigger 'apply' from Memory view, Explorer view and command palette
• Use nrf-intel-hex library for read/write file licensed under BSD-3

Use quick inputs to guide user through necessary input

• Initialize as much of the input as possible through command args

Communicate with webview through messenger requests and notifications

• Request to trigger store and apply from webview
• Notify webview about any written memory so it can update properly

Minor improvements

• Move some common types and functionality into 'common' area
• Avoid bleeding Debug Adapter types into webview, use messaging types
• Common style: 'getVariables' -> 'getVariablesType'
• Provide utility functions and types for debug requests
• Fix 'Enter' handling for numpad by checking key value of event

https://github.com/eclipse-cdt-cloud/vscode-memory-inspector/assets/19170971/9c3e2772-cfd5-4b7c-8d45-e2707338d0cb

Closes #50

How to test

• Run a debug session
• Check how you can store memory (from the inspector, from the command, from the Variables window)
• Try applying your stored memory (from the inspector, from the file context menu, from the file explorer context menu)

Review checklist

• [x] as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[martin-fleck-at]

@colin-grant-work Thank you for your detailed feedback! I tried to address everything in a follow up commit (after a rebase) and added another commit on top based on the feedback from Jens. Besides the type placement, I think I have addressed everything.

[jreineckearm]

@martin-fleck-at , re-tested functionality.

Did the ultimate test with storing memory from one of our existing debug tools to a hex file. And applying it with the Memory Inspector. And vice versa. Looks all healthy! :-)

The recent change to connect a memory window instance to a debug session ID has the unfortunate side effect of not being able to reuse a memory window anymore. This was possible, would be good to get that back. Use case: I debug something and use the Memory Inspector, I make a code change, then restart debug, and would like to inspect related changes in the previously opened window instance.

Some minor suggestions inline.

One bigger change that may be required and is possibly out of scope for this one is to honor MS-DAP memory events. Our debug adapter correctly sends them on memory contents change. But I see that the Memory Inspector debug tracker doesn't make use of them to trigger a refresh if in the loaded memory range of a window instance. At the moment you need to manually trigger a refresh after loading a hex file into memory.

[martin-fleck-at]

@jreineckearm Thank you very much for your feedback! I rebased the change and added the new functionality on top: The memory inspector should now properly refresh automatically and we also support the memory event as requested here: https://github.com/eclipse-cdt-cloud/vscode-memory-inspector/issues/105.

Furthermore, I added the missing context menu entries for https://github.com/eclipse-cdt-cloud/vscode-memory-inspector/issues/51.

Could you please have another look at it?

[colin-grant-work]

Quite a few changes since my last look - I'll read things over later today.

[martin-fleck-at]

@colin-grant-work Thank you very much! I added them as separate commits so it shouldn't be too bad, I hope! I'll do a quick rebase then.

[martin-fleck-at]

@colin-grant-work @jreineckearm Everything should be good to review again ;-)

[jreineckearm]

Thanks, @martin-fleck-at !

From a functionality point of view, things work as outlined in your last comment. This is a really nice new feature!

• Reusing existing and configured Memory Inspector windows for subsequent debug sessions works again.
• The apply/store buttons are now disabled if debug session is not active to prevent users from provoking errors when functionality simply can't work.
• Context menu has been extended by the two commands. Getting crowded there. Need to consider grouping commands by sections/sub-menus when adding new functionality. But I guess we need think about a similar "redesign" for the in-window options menu going forward.
• Apply/store still works as expected.
• Open and save dialogs now start at ${workspaceFolder}.
• "memory" event support works nicely. I can see the effect now when editing variables and using commands in the Debug Console of our Arm Debugger debug adapter extension.

Minor improvement for later (not this PR)

• We have a context menu entry on the variables view to store data for variables living in memory. But there is no counter-part to quickly load a data set into a variable.

[martin-fleck-at]

@colin-grant-work @jreineckearm I pushed an update that should address the latest concerns.

[martin-fleck-at]

@colin-grant-work Thank you very much! I'll push an update for the decimal address support in a few minutes!

[martin-fleck-at]

@colin-grant-work If you agree with the latest commit, please feel free to merge this PR.