Support tmpfs and a server queue for C++ compilers

[tolk-vm]

tmpfs

This PR drops an option -working-dir, adding two new instead:

• -cpp-dir {string}, Directory for incoming C++ files and src cache, default /tmp/nocc/cpp
• -obj-dir {string}, Directory for resulting obj files and obj cache, default /tmp/nocc/obj

The directory passed as -cpp-dir can be placed in tmpfs.
All operations with cpp files are performed in that directory:

• incoming files (h/cpp/etc.) are saved there mirroring client's file structure;
• src-cache is placed there;
• pch files are placed there;
• tmp files for preventing race conditions are also there, not in sys tmp dir.

So, if that directory is placed in tmpfs, the C++ compiler will take all files from memory (except for system headers), which noticeably speeds up compilation.

When setting up limits to tmpfs in a system, ensure that it will fit -src-cache-limit plus some extra space.

Note, that placing -obj-dir in tmpfs is not recommended, because obj files are usually much heavier, and they are just transparently streamed back from a hard disk in chunks.

C++ compiler queue

nocc-server now managers C++ compiler launches with a waiting queue. The purpose of a waiting queue is not to over-utilize server resources at peak times.
Currently, amount of max parallel C++ processes is an option provided at start up via max-parallel-cxx (in other words, it's not dynamic, nocc-server does not try to analyze CPU/memory).

Other improvements

• less disk lookups in general; for instance, mirror client's dir structure in advance, avoiding calling os.Mkdir on making a hard link from src cache or uploading a file
• server start up becomes quicker, as old dirs are deleted in the background
• client start up becomes quicker, as in connects to all remotes in parallel
• send NOCC_SERVERS on a client connect and maintain uniqueRemotesList on a server-side to detect clients with weird env vars

This release bumps version to v1.2.