Merge pull request #1508 from ppekrol/master

2.5 to 3.0 merge
Removed the xunit reference from Raven.Tests.Helpers project and modified the code to use System.Diagnostic methods for assertions
changed the code in Raven.Tests.Helpers/RavenTestBase.cs to throw exception in stand of the XUnit assertions
Merge pull request #1507 from talweiss1982/master

Removed the xunit reference from Raven.Tests.Helpers project and modifie...
Fixing race condition in test
Move ravenfs tests to higher order in the test execution order
Merge branch 'master' of github.com:ayende/ravendb
Trying to make sure that we can't miss directory creation
Getting serious checking that we can actually write to those directories
RavenFS can be used by OSS users
Merge branch 'master' of https://github.com/ayende/ravendb
Merge branch 'master' of github.com:ayende/ravendb
RavenDB-2849 Pages freed with asOfTxId == -1 should be treated in a special way because they are available immediately to allocate. That fixes the bug in calculation of ActivelyUsedBytes. Also when doing calculation of ActivelyUsedBytes do not sum pages by allocated size but by number of pages that they really use.
RavenDB-2849 Fixing the calculation of sizeAfterAllocation when there are multiple scratch buffer files. Ignoring TimeoutExceptions when a flush to data file was forced. Fixing and adding more debug info message when scratch full exception is thrown.
RavenDB-2850 Switching to recursive locking to avoid IsWriteLockHeld usage (according to MSDN doc this property should be only used for debugging purposes)
RavenDB-2849 Fixing NRE
RavenDB-2849 Changing the approach we create transactional storage's batches when doing bulk insert for better support of concurrent bulk inserts on Voron storage (what is done by Smuggler for instance). The problem is that a call of TransactionalStorage.Batch creates a snapshot (a read transaction) which prevents  Voron from flushing a lot of data that could be potentially read by any transaction. That in turns caused ScratchBufferSizeLimitException. The general approach for potentially long batch operations should be to call Database.DocumentLock.Lock and after that call TransactionalStorage.Batch otherwise we create the unnecessary snapshot that blocks freeing scratch pages.
Merge branch 'master' of git://github.com/ayende/ravendb into RavenDB-2849
RavenDB-2849 Apply the same approach in opening transactional storage's batches for replication like for bulk inserts - first acquire the lock then open the batch
Temporarily disable ravenfs licensing