policy monitor improvements

#1744 highlights issues caused by the monitor and coordinator
we are going to remove the coordinator with #3131.

However there are still improvements that we can make to the policy monitor:
- We create a goroutine per agent policy, as the number of policy is low this is perfectly fine, but I think that logic could be handled by a single cleanup event loop in a single goroutine.
- Improve handling when a large amount of policies are defined; `monitorT.polices` is a `map[string]policyT`. This works for low policy counts but will likely need to be another data structure such as an LRU cache in order to support larger counts

Other areas that may need more investigation are:
- We are exposing internal fields from monitorT object in the test suite, we should hide all access to the internal field using accessor even if this is only for testing. This allow a single locking logic.
- Looking at the code, It look like possible the usage of multiple internal fields into a watcher struct that would encapsulate more logic.
- Internal state of the monitor bleeds into the goroutine execution, this make it harder to lock or prevent concurrent access to the resource. Encapsulating that logic into his own object would make it simple to test and verifies.