Implement session suspension (like RStudio)

RStudio has a unique feature wherein sessions can suspend to disk, preserving all objects in memory, IDE layout, environment variable values, etc. etc, such that when the session is later resumed, it appears to the user just as it did before being suspended.

This feature is very useful in resource-constrained environments because it allows compute and memory to be released after a fairly short idle period without running the risk of losing any user data; users get seamless resumption of sessions when they return to them and may not even need to know that the session went to sleep.

In IDEs other than RStudio on Posit Workbench, however, if you don't want users to lose data, your only option is to let the session stay in memory; for example, see this section about VS Code sessions:

https://docs.posit.co/ide/server-pro/admin/vscode_sessions/configuration.html#idle-session-timeout

We should consider adding this feature to Positron, such that Positron Pro sessions would join RStudio Pro sessions in the set of those that can be suspended to disk after an idle timeout.

While this feature is very popular with system administrators, it has also come with some problems of its own that are worth thinking about before attempting to implement it in Positron:

• A common problem in RStudio is getting yourself into a state wherein your session is basically unusable because it cannot be resumed, often because it is too large. We would need defenses against this in Positron.
• Similarly, suspended sessions overflowing user disk quotas are also a problem that many customers encounter (and are especially of concern with Positron since a single Positron session contains many individual interpreter sessions).
• Communicating feedback during session restoration is very important (and RStudio can't do this well for architectural reasons). Positron should show which sessions are being restored, and also report cancellable progress during restoration as objects are reloaded. See e.g. https://github.com/rstudio/rstudio/issues/4345
• There are a variety of things that cannot be serialized/deserialized to disk; if one of these is present, we cannot suspend the session. Historically "why isn't my session suspending?" has been a common enough question that we've had to add UI to help users and admins know what's going on.
• RStudio has an easier time with suspension because it only needs to handle one R session. Positron may need to serialize multiple R and Python sessions (and others). Language runtimes would need to expose hooks for triggering suspension. Implementing those in e.g. Python could be difficult since Python doesn't have the same serialization support R does (maybe we'd build on pickle?)

No files, tests, or entry points are identified. Start by mapping Positron's session lifecycle and its R and Python runtime integration. Done requires a design that covers persistence, disk quotas, restoration progress and cancellation, unsupported objects, and multiple interpreter sessions.