Configurable timeout and retry for the writelock and improve logging

**Is your feature request related to a problem?**
Yes.

While running the tests of the dependency-check-gradle plugin I was waiting without any progress feedback due to a failing writelock (likely due to a previously early-kill of a test that appeared to not progress at all. When I finally kept it running for 'forever' it gave up (failed on an exception) after 40 minutes as it could not obtain the WriteLock.

**Describe the solution you'd like**
As the WriteLock is used for cases than only the NVD CVE database update we should make it at least development-time configurable, so that locking for RetireJS and the hosted suppressions will time-out much sooner.

Maybe even allow end-user overrides for the 'patience' of (some of the) individual locking attempts (so that users can reconfigure to a shorter timeout on their builds when a dedicated job to e.g. daily update the NVD CVE datastream ensures that only CVE modified needs to be processed so that the updates should finish much sooner).

Currently only when the user has enabled debug logging there is some information logged that an update is waiting for a lock.
It would be good if there is at least once, and preferably every x minutes, an INFO-level log that the system is (still) waiting to obtain a lock so that users are aware that a lock is in the way of progressing the build (when it is the only build running on the system they know that there is a stale lock locking them out).

**Describe alternatives you've considered**
Keep the current code so that any locking attempt with a stale lock will require the user to wait 40 minutes to see their build fail on the lock timeout exception.