Switch to long-lived container resolvers

[mstemm]

Instead of having container engine objects be short-lived, only created
at the instant resolve() is called, have them be long-lived and a part
of the sinsp_container_manager object. This involves:

• create a stub base class libsinsp::container_engine::resolver that
  defines virtual void resolve() and virtual cleanup() methods.
• making all the classes in container_engine/* derive from the base
  class.
• in sinsp_container_manager, create a list of
  container_engine::resolver objects.
• when resolving containers, iterate over the list instead of using the
  templated functions resolve_container_impl().

This fixes SMAGENT-1569, because there is no global state related to the
container engines.

[adalton]

All nits.

[gnosek]

While the code changes look okay at a glance, I still fail to understand how that helps with locks held over a fork.

[mstemm]

The reason this helps with forks is that some tests did a exit() in a forked child, which close all FILEs, call the destructor of all globals, etc. Since it's a forked child, the destructors were being called twice (in parent + child), and that caused a hang due to one of the semaphores. The corresponding agent PR had a test that explicitly triggers this--aside from this change, I could make the test fail/pass by switching between exit() and _exit() (which skips all that teardown stuff).

[gnosek]

I just realized exit() only calls destructors of statics/globals, not of local variables, so moving from one to the other will indeed help.

[mstemm]

@adalton and @gnosek, I made some additional changes to defer creating the container engines until the first call to resolve_container. This allows time to specify an alternate cri socket path, timeout, etc. I'd like to get your feedback. I didn't go the full step of moving the static values like the socket path, timeout, etc out of libsinsp/cri.cpp, but if you feel like it's better to move them into the cri engine, let me know.