waters_connect support in Skyline and pwiz

[chambm]

• added support for downloading data from waters_connect with a URL like: https://devconnect.waters.com:48444/?sampleSetId=<sample set id>&injectionId=<injection id>
• added support for connecting to and browsing waters_connect servers in Skyline
• added folder hierarchy for remote accounts in the "Look in" dropdown for OpenDataSourceDialog (previously only worked for disk drives)

• redirected UNIFI to use ABI's protobuf-net.dll (I don't think it was ever actually using the unifi-protobuf-net.dll)
• refactored ParallelDownloadQueue into a separate class shared by UnifiData::Impl and WatersConnectImpl (a new implementation derived from UnifiData::Impl, but WatersConnect uses a separate queue for each channel)
• added optional performance timers in VendorReaderTestHarness
• disabled lockmass prompt for UNIFI in Skyline as it does not support it
• improved error handling in Skyline UNIFI browsing
• refactored and renamed existing UNIFI tests to work for both APIs
• added SRM SIC prefix to UNIFI SRM chromatograms
• added extraction of precursor and product m/z for SIM/SRM chromatograms from metadata if parsing from id fails
• added scan polarity to GetChromatogramMetadata

• Refactor pwiz UNIFI stuff as RemoteApi (e.g. SpectrumList_RemoteApi)?

The folder hierarchy for remote accounts looks like this now:

Previously it was impossible to tell where in the hierarchy you were.

[nickshulman]

Looks good to me.

[chambm]

In this latest update I had to make significant changes to support browsing directly to a nested waters_connect path (rather than browsing to it manually by clicking on each folder starting at root). The W_C API allows getting the entire folder hierarchy in one call, but we also treat "sample sets" as folders (because they are collections of injections, which we treat as files), and those must be retrieved one at a time (first by looking for sample sets in the containing folder, and then by looking for injections in the sample set). Because we specify paths in the waters_connect:// URL by path parts (e.g. path/to/some/data), and /data may be a sample set instead of a folder, we must make a couple extra API calls to figure out the folderId and sampleSetId when browsing directly to a path.

If we stored sampleSetId, folderId, or injectionId in the waters_connect:// URL instead of the slash-separated path, then we could probably avoid making some of those API calls: we could set the EncodedPath after only looking up the folderId in a sample set's metadata. I just mention this as context for the PR because I don't think it's worth it to change just to cut down on a few calls to the server.