Asynchronous library completions for search path

Not quite ready for merge -- @jjallaire, I'll need your help to fill in a few missing pieces + verify I am doing some mutex locking safely / sanely. I still need to fill in some bits on the R side + later fix merge conflicts.

This PR brings asynchronous completions for search path items from `library` calls. The idea is this:

1. We scan the source document for `library`, `require` calls,
2. We collect those package names,
3. We launch an R process that gets the namespace exports from those packages,
4. We send the results back as JSON (which we then decode appropriately),
5. We then store all completions on the server, and provide them for autocompletion lookups.

To facilitate this, the `RSourceIndex` class now has a (singleton) static member `completions_`, which maps package names to completion items. The `AsyncRCompletions` is the driving class (it inherits from `AsyncRProcess`) and makes the necessary R call to generate completions. For simplicity, we try to ensure that only one async completions R process is running at a time, but make it possible to kick off new updates as frequently as necessary.

Basically, we treat the `AsyncRCompletions` class as a single singleton process, which attempts to make (thread-safe) updates to the `completions_` static member of `RSourceIndex`.

Note that this currently does not work for unsaved documents -- I was under the impression that the document ID would be sufficient for locating the server-side cache of unsaved documents but it appears I was incorrect or am missing some pieces.

Main question for now -- when would it be appropriate to attempt an update of the completions index?

It also appears that I'll need to do something specifically to handle suspend + resume; it seems like some insidious / bad things can happen there, especially if there is an async process running while we suspend.
Why not just make this a static member (i.e. why have an accessor function at all)