Exports file to temporary location if target is locked

[AmadeusW]

Fixes #414
When a target file exists and is locked, currently BDN crashes and some of the data is lost.
This PR makes BDN export data under randomly-unique name to a temporary location and print a message to the log:

// * Export *
Could not overwrite file C:\src\BenchmarkDotNet\samples\BenchmarkDotNet.Samples\BenchmarkDotNet.Artifacts\results\Algo_BitCount-report.csv. Exporting to C:\Users\amadeusz\AppData\Local\Temp\uvkf5nub-Algo_BitCount-report.csv
  C:\Users\amadeusz\AppData\Local\Temp\uvkf5nub-Algo_BitCount-report.csv
  BenchmarkDotNet.Artifacts\results\Algo_BitCount-report-github.md
  BenchmarkDotNet.Artifacts\results\Algo_BitCount-report.html

I'm not fully convinced that this sufficiently notifies user that the report in expected location is out of date, but I think this is better than data loss after a long running benchmark.

[dnfclas]

@AmadeusW,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

[adamsitnik]

I like the idea, but I think that we should save the file to summary.ResultsDirectoryPath, not Path.GetTempPath().

Perhaps the name should be time-dependent by default? So our users could compare the results easily.

[AmadeusW]

How about this? It yields a unique representation and follows ISO 8601

Is the message superfluous, and we could remove the second sentence?

// * Export *
Could not overwrite file C:\src\BenchmarkDotNet\samples\BenchmarkDotNet.Samples\BenchmarkDotNet.Artifacts\results\Algo_BitCount-report.csv. Exporting to C:\src\BenchmarkDotNet\samples\BenchmarkDotNet.Samples\BenchmarkDotNet.Artifacts\results\Algo_BitCount-report-20170409-192535.csv
  BenchmarkDotNet.Artifacts\results\Algo_BitCount-report-20170409-192535.csv
  BenchmarkDotNet.Artifacts\results\Algo_BitCount-report-github.md
  BenchmarkDotNet.Artifacts\results\Algo_BitCount-report.html

[adamsitnik]

@AmadeusW I really like it!

@AndreyAkinshin what is your opinion on that?

[AndreyAkinshin]

It's a common problem, so I really like that now we will have a solution for such cases.
@AmadeusW, thanks for the PR! Could you also write an integration test for it? It should be easy to write: just create *-report*.csv in advance, lock it (e.g. start to read from it), run a benchmark, check that we created this report with another name. I'm asking about it because we are going to implement other file creation issues (see a related issue: #377) and I want to be sure that future fixes will not break this one.

[AmadeusW]

For sure

[adamsitnik]

@AmadeusW once again big thanks!