Add ephemeral storage for extensions

[lionel-]

Branched from #12545 (base branch still set to main so CI runs tests)

Experimental addition of a new kind of persistent storage context.ephemeralState that is:

• Unique per workspace and process.
• Stored in-memory only

This storage matches exactly the scope/lifetime of console sessions, and is thus an ideal place for extensions to store metadata about console sessions.

The positron-run-app extension now uses this storage to keep track of sessions (see #12545). This has these advantages:

• Extension state written to workspace storage could be invalidated / corrupted when multiple windows with the same workspace are opened (e.g. via "Duplicate as workspace in new window" command). The ephemeral storage prevents this sort of races by design.

  Edit: As pointed out by Jonathan, this is not true. There is a file-lock mechanism for workspace storage and the duplicate as workspace command creates a new, separate workspace with its own storage.

• Not taking up disk space for state that is only relevant in the context of a running instance and that could easily be leaked forever. For the app runner, we still prune console sessions when we look them up to avoid unbounded growth while the instance is running. If it didn't prune though, the ephemeral storage guarantees the state is cleaned up on shutdown, rather than leaked on disk.

New Features

• N/A

Bug Fixes

• N/A

QA Notes

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical

^{readme  valid tags}

[jmcphers]

Thank you for doing this, I've been meaning to do so for months!

Two small requests:

• Update the comment re: workspace corruption; it is my understanding that workspace state is appropriate for per-window operations because you can't open the same workspace in two windows at once.
• Putting an API in vscode.d.ts makes it difficult/impossible for third party extensions to use, because, unlike positron.d.ts, we do not publish our modified copy of these types anywhere. What do you think about moving this to positron.d.ts? Realize then it can't be part of ExtensionContext, but we get the extension ID as part of every API call so it could just live on e.g. namespace window.