Fixes an issue for negative BrickElement lock count

There were an issue with the if-statements in
BrickElement#getAndMarkWindow() where the brick wasn't always locked,
although it should have been every time before a persistence row was
created over a record, and yet it was always unlocked after use. This
resulted in negative lockCount on BrickElement. Funny how that didn't
cause problems, such as indefinite wait in allocateNewWindow which
contains a loop that awaits lockCount == 0.

Added an assertion for lockCount being equal to or greater than 0. There
are already some tests that failed by just adding that assertion and not
fix the lock counting issue. That's why this commit has no explicit tests
for the issue.
Don't push Desktop artifacts

As the Maven server doesn't care for it, and it fails the build.
We could fix that on our own Maven server, but it's less likely
that the Maven Central guys will want to do the same.
Merge pull request #1340 from tinwelint/1.9-fix-negative-pwp-lock-count

Fixes an issue for negative BrickElement lock count
Added missing asciidoc formatting.
Test for persistence window pool brick lock issue

See commit 723933f275bc2f366ad82ce95784fb18d29852fd for the commit that
fixed the issue, also description about the fix there. This is a test to
verify that behaviour.
Merge branch '1.9-maint' into wildcardcluster
Adds proper store directory to arbiters so they log normally