Multiple instances of semantic completer

While the previous PR was still pending I got PR's from @mispencer, two of which included here.
This PR brings two features:
- Enable redirecting the server output to files instead of /dev/null in order to make debugging easier.
- Enable multiple instances of the completion server (at different ports) to allow working on different projects at the same time.

Especially the latter problem is rather tricky, and its hard to say if the offered solutions are the best ones, so I suppose this will require some discussion.

To redirect the server output, two new vim variables are introduced allowing the user to specify the file name for the stderr and the stdout. An alternative solution could be to have fixed file names (parametrized by the port number) in some log directory. This would remove the need for two new vim variables. I don't know which solution is preferred.

To enable multiple instances of the completion server, the completer tries to find a new port by scanning upwards from the initial port until a port is found with no omnisharp instance running on it. This will work almost always. But this does not cover the case where a different application is using one of those ports. It appears to be rather tricky to solve this neatly. 
- You cannot determine the free port in the python script, and pass it to the server, because in the meanwhile another application could have taken the port.
- You cannot let the server choose a port, because then the port is unknown to the script.

We could use a trial-on-error approach and pay attention to the stderr of the completion server. This sounds rather difficult and messy to me though. Any thoughts about this?

Although this PR specifically applies to the C# completer, I suppose that other future completers with a client-server architecture are likely to encounter these same problems so it might be worth it to solve these problems thoroughly.