Changing first workspace folder restarts extensions

[amp343]

Issue Type: Bug

Changing the first folder in a workspace restarts the extension host.

This is a problem because it breaks the extension's ability to listen for workspace lifecycle events like workspace.onDidChangeWorkspaceFolders (the extension cannot catch an event that changes folder 0 since it's being restarted).

VS Code version: Code 1.21.1 (79b44aa, 2018-03-14T14:39:09.335Z)
OS version: Darwin x64 17.3.0

Reproduces without extensions

[amp343]

This issue directly affects extensions that use the proposed FileSystemProvider api (https://github.com/Microsoft/vscode/blob/master/src/vs/vscode.proposed.d.ts#L227).

Test:

1. An extension registers a filesystem provider with workspace.registerFileSystemProvider for a certain scheme (e.g., ftp)
2. Adding folders to the workspace that have this scheme work fine; that is, they are handled by the intended provider ✅
3. Moving folders around that affect the first folder in the workspace breaks this pattern though; the extension restarts, and the mapping between scheme and provider is lost (even if the extension re-establishes it on its activation event). Workspace files that have been fetched with the intended provider will now attempt to be accessed with the default filesystem provider, resulting in ENOENT etc. ❌

This can be confirmed with the https://github.com/jrieken/ftp-sample extension, or another similar implementation.

Hard to see, but the workspace root served by the ftp provider goes empty and throws an ENOENT after the first workspace folder is modified (its extension is restarted).

[bpasero]

Unfortunately this is by design so that we do not break our deprecated rootPath property in the API that is always the first root folder but cannot change during runtime without a restart.

/cc @jrieken