[refactor] merge pod watchers

[balopat]

#3645 introduces the 3rd podWatcher based control loop in skaffold with the exact same control flow.

I would think a single podWatcher would be less resource intensive (the same "event messages" only need to be sent once for skaffold) on the API server side and on the skaffold side as well (less go routines).

I think, in a separate PR we should refactor first to a "visitor" pattern on a centralized podWatcher and make the logs, portforwards and debug listeners "register" / "unregister" with the podWatcher.

In this visitor framework the implementation of the debug listener only would require line 94-99.

Originally posted by @balopat in #3645

[briandealwis]

@nkubala will the deploy refactoring address merging the various pod-watchers into a single instance?

[nkubala]

I don't think this is an issue anymore. we do share one instance of a pod watcher now - there is one PodSelector per Runner instance which is passed to all sub components. the control loop logic (e.g. the calls to watcher.Select(pod)) needs to happen on a per-component basis, so I think we've done as much optimization as we can on this front.