Add new PeakInvestigator library class and TOPP tool

This pull request is to add a new class to the library (TRANSFORMATIONS/RAW2PEAK) and a new TOPP tool. PeakInvestigator is a tool/library that calls the public API provided by Veritomyx (see www.veritomyx.com), and handles all of the steps required for submitting scans to Veritomyx's cloud platform including reading raw continuum data, bundling scans for upload, transfers to/from a SFTP server, extracting and saving the resulting peak lists.

As discussed with @okohlbacher and @timosachsenberg, this PR is to get the conversation started with the other developers.

A few notes:

1) It currently depends on ```libssh``` for SFTP transfers. This will be removed in the future due to being licensed under the LGPL. Before I put in several hours converting to ```libssh2``` (BSD-like license), I wanted comments to know whether my current approach is ok. Specifically, on Windows, a system call is made to PSCP (Putty's scp client) since it is complicated to install ```libssh2``` and its dependencies (namely ```openssl``` as raised by Timo). However, it should be trivial to install ```libssh2``` on Mac and Linux, so the calls to that library are maintained. If this approach is still not acceptable, then I will find another approach for Mac/Linux.

2) Oliver and Timo said the direction of OpenMS will be to trim down the library, especially for classes that aren't re-used. In particular, it may make more sense for PeakInvestigator to be implemented only as a TOPP tool (or UTIL program). My preference would be keep it as both a library and tool so that other developers can leverage the bulk of the code (i.e. the library class) in their own applications, but I understand the goals of the OpenMS team.

3) As I mentioned on the mailing list, Veritomyx is in the process of modifying our public API. The new API is still in development, with a planned release in the next few months. Once we move to our new API, the current (beta) API will be discontinued. If this PR is to be accepted before the 1.12 release, I will need some time to add support for the new API and a smart fallback mechanism to choose the correct API.

4) If it is decided that a TOPP or UTIL program is more appropriate, I'll alter the my code and create another PR. Should there only be a single source file like the other TOPP and UTIL programs, or is it permissible to have an extra class as well? 

5) I've taken an initial stab at the Documentation, but it still needs work.

I look forward to hearing your comments.