FileTarget - Perform archive retry when concurrent file access

[snakefoot]

Extended Fix for #1887. Perform archive-retry when doing concurrent file-access.

Minor refactoring of BaseMutexFileAppender to make it easier to use. Inheriting from the class activates the archive mutex by default.

---

This change is 

[snakefoot]

Should probably implement a test to show the archive-mutex is likely to work for #1887 and #1513

[codecov-io]

Codecov Report

Merging #1889 into master will decrease coverage by <1%.
The diff coverage is 50%.

@@           Coverage Diff           @@
##           master   #1889    +/-   ##
=======================================
- Coverage      82%     82%   -<1%     
=======================================
  Files         304     304            
  Lines       21106   21126    +20     
  Branches     2519    2528     +9     
=======================================
- Hits        17264   17247    -17     
- Misses       3211    3248    +37     
  Partials      631     631

[snakefoot]

Test implemented, but apparently the archive mutex is not working well on the MONO-Platform (Even when using the Retrying-FileAppender). Disabled the archive test for MONO

And it also seems that the concurrent-tests with async-wrapper is throwing random exceptions. And sometimes the files remains locked after process exit (Failing to cleanup temp-directory after completed test). Disabled throwing exceptions when non-archive test.

[snakefoot]

Seems named Mutex (and named Semaphore-logic) has been removed on the Linux-platform with MONO ver. 4.4 (and has been disabled by default since MONO ver. 2.8)

I guess a possible solution for the missing Mutex-handling in MONO (and .NET Core) on Linux, could be to create a subfolder in the file-logging-directory. And create a lock-file with the mutex-name for mutual-exclusion.

Maybe an alternative way could be FileStream.Lock() and FileStream.Unlock(). Then the lock-file could be kept open, and not suffer a huge penalty for opening (and closing) the lock-file. Guess the same approach could be used to create a cross-platform FileLockMultiProcessFileAppender.

[snakefoot]

@304NotModified Synchronized with master, and after further discussions with myself decided not to change the naming of the mutex. Instead I have just changed this PR to allow retry to cater for concurrent file access issues (Like the retrying-file-appender attempts).

[snakefoot]

@304NotModified This is no longer a breaking change, and should improve stability of SimpleConcurrentTest (#2198)

Will actually improve stability for all multi-process-file-writing with archive-logic enabled.

[304NotModified]

great work!