Use Windows Mutex to implement object cache locking

This works better in case clcache gets terminated abnormally, in which case you
might end up with stale lockfiles. A mutex won't have this problem, the handle
is released when the process terminates.

A mutex might also be faster since there's no disk access anymore.

This patch is mostly courtesy of Vyacheslav Chigrin <vchigrin@yandex-team.ru>,
he did most of the work as part of commit
72094faa06eaba468c2cafc57d9137d96ff3aadd.
When cleaning the cache, clear the oldest object files first

Vyacheslav Chigrin <vchigrin@yandex-team.ru> pointed out that as code evolves,
old object files are less likely to be reused. I tend to agree, so let's sort
the list of object files so that those with the oldest access time are first in
the list, so that we delete them first.
Fixed grave bug when computing cache key

It turned out that when computing the cache key (and when invoking
the preprocessor!) we always droppd the first item from the given
'commandLine' argument. This got broken by commit
ca1c51404e3835b2e9f754161071cce238c073e3 which caused 'commandLine'
to only contain the arguments to the compiler, not the actual
compiler itself.

The cache key computation code still assumed that the first element
of the command line is the compiler binary, so it skipped that.

This bug not only caused some builds to break (because e.g. important
include paths were missing!), it also means that the first compiler
argument was not taken into consideration when computing the cache
key. So compiling the same soruce twice, but with slightly different
compiler invocations which only differ in their first argument, would
incorrectly result in a cache hit.