Consider discarding the memory cache only when the target stops, and not when the target resumes

[xusheng6]

Right now we discard the memory cache as soon as the target resume execution. This is technically right, since once the target is running, all the memory content we are seeing are no longer up-to-date. However, this also causes certain problems, especially when the target will be running for a while (e.g., waiting for some console input) and it does not stop again immediately. This can cause several issues:

1. Since the backing memory has gone, the analysis can change in subtle and hard-to-perceive ways. One user reported the strings are gone (i.e., those constant strings are no longer shown), and the underlying cause is those bytes are no longer readable when the target is running. Worth still, if the user is brave enough to update the analysis, the entire function will become a question mark, again, because the memory bytes are gone and the analysis cannot do anything.
2. If I wish to add a breakpoint somewhere while the target is running, it is also very tricky, since if I navigate to another function, chances are its analysis will be updated automatically, and the function becomes a big question mark, and there is no way to add a breakpoint. The only workaround is to pause the target, add the breakpoint, and then resume it. Which is a bit counterproductive

In light all of this, I suggest we should only keep the memory cache while the target is running, and only discard it when the target actually stops and becomes accessible again.

[xusheng6]

Also -- for consistency, should we also keep everything else, e.g., registers, stack traces, etc, while the target is running?