Refactor py-spy & pyperf to separate ProfilerInterface classes

[Jongy]

We have PythonProfiler which is a class that hides the fact that we have 2 profiler types behind - py-spy or pyperf, and decides itself which one is used.

The decision needs to move out, and each of py-spy & pyperf should implement the interface and be registered separately. This way they can have different settings in their register_profiler decorator, as suggested here: https://github.com/Granulate/gprofiler/blob/4bcb3aedae1c286d3058a0dc0f559cf88fe5e940/gprofiler/profilers/python.py#L279

This also removes the need for the PythonProfiler itself (which directs calls at the different underlying classes).

Instead, for each "runtime" such as "python", we'll have a function select_profiler that gets the mode requested by the user and the list of available profilers (given the architecture & platform) and will run the necessary tests to decide (what is currently implemented in PythonEbpfProfiler.test)

[Jongy]

#448 is caused by this merge into PythonProfiler - it introduces room for errors.

[marcin-ol]

Instead, for each "runtime" such as "python", we'll have a function select_profiler
So a central authority to select proper profiler?

How about letting candidate profilers report their readiness, via e.g, readiness_check()?

gProfiler would group profilers by their runtime, let them report their status and select the one that is ready.

[marcin-ol]

I believe we would also need to mark one profiler as preferred for runtimes that have more than one.

[Jongy]

I believe we would also need to mark one profiler as preferred for runtimes that have more than one.

Agree.