Fixed the problem with with testRuntime and testCompile configurations resolved eagerly, even when no tests were present.

1. Added @SkipWhenEmpty annotation where needed. Removed @Input annotation because it didn't add any value. Fixed the integration tests.
2. This change may improve performance and heap consumption of certain builds (large multi project builds with little tests).
REVIEW-2455 Tweaked the javadoc to reflect the recent changes.
REVIEW-2455 Injection of the executor factory. Technically, it's not injected ATM, as there doesn't seem to be a good reason.
REVIEW-2455 Removed unnecessary method from MultiProcessSafePersistentIndexedCache.

Reworked the DefaultCacheAccess cache a little bit to make above change possible (cannot clear the lock owner thread before closing the lock).
REVIEW-2455 Updated javadoc.
REVIEW-2455 Attempted to unify the implementation of FileLockContentionHandlers.

1. The attempt has failed. Down the road we want to have a single FileLockManager per process. Getting to that point is not trivial however. The default file lock manager opens a datagram port before creating a lock and requires the clients of the locks to provide reasonable callbacks when lock contention happens. At the moment, we use the default file lock manager in few places where the lock contention handling is absent and adding it is tricky (I'm open to suggestions). Hence perhaps we allow the no-op implementation of lock contention handler in those places for the time being until we have a better reason to push harder for a single file lock manager per process.

2. Rename job and refactoring. Added dedicated method for enabling file lock contention handling on the file lock manager.
Revert "REVIEW-2455 Removed unnecessary method from MultiProcessSafePersistentIndexedCache."

The change was not quite ready and made some tests upset.

This reverts commit bc87de9d3a5ec8409abc2102a0450c0cc75e0dae.
REVIEW-2455 Removed unnecessary method from MultiProcessSafePersistentIndexedCache.

1. I needed to relax the validation of getLock() method. Currently, it is possible that the close operation is invoked on a cache that does not have any owner thread (see the unit test). I'm not sure if this approach is good - please review.
2. Reworked the DefaultCacheAccess cache a little bit to make above change possible (cannot clear the lock owner thread before closing the lock).
REVIEW-1702 Added more integ test coverage for parallel execution.
Recent change that avoids eager resolution of testCompile and testRuntime configurations also fixed a minor problem with '--no-rebuild' switch. Updated the integ test to reflect that.
REVIEW-2297 Simplified the unit test
REVIEW-2302 Started using strictlyEquals in one of the unit tests.
Attempted to fix one of the threading issues in the file lock by reworking the contention handler. Simplified the FileLockCommunicator - it is now almost immutable (there's only stop() method) and hence less prone to threading issues.
Merge branch 'master' of github.com:gradle/gradle