Fixed parallel issue with build execution listeners.

1. Reverted the previous fix (e.g. concurrent map in the TaskExecutionLogger)
2. Fixed the problem where the notifications are triggered, this way all implementations of the TaskExecutionListeners, including user's will be safe for parallel build.
In-memory dependency metadata cache no longer uses soft references.

1. As I wrote in the spec, I don't think it is a good idea to use soft references. We also received similar feedback from our users. This cache consumes little percentage of heap but soft references may degrade gc performance. When the app reaches heap limit, the resources cleaned up from this cache won't help much and the app will continue to gc-thrash. I've tested the behavior of the build on a huge project and using soft references or not does not give any conclusive results. However, the common sense hints at avoiding them.
2. We need a good strategy for limiting the caches. Now there are 3 instances of in-memory cache that we should look into finding a consistent approach:
  - task history cache (preserved across builds in the daemon), currently uses fixed items cap
  - resolution results cache (per build), fixed items cap
  - dependency metadata cache (this cache), no cap
 We could use guava CacheBuilder and weight the size of the cache against available heap. This can be combined with other strategies, like items cap, expiration

 Using a soft reference here would arguably make things worse when the app