java: Show a "profiling skipped" stack when profiling is skipped for a process

[Jongy]

Description

When profiling of a process is skipped by gProfiler for whatever reason, the following happens:

• In perf-less mode (--perf-mode=none) - we won't see its stacks and we won't know it existed.
• In standard mode, gProfiler will use the samples collected by perf (if any) when merging the stacks. So we'll see the native Java code, which is seldom interesting.

This PR amends the Java profiler to return a specialized stack per "skip" case (safemode, AP already loaded in a process, ...). This way, the user sees the cause of the error immediately, and doesn't have to skim through the logs in order to understand. Also, it makes the skip explicit ("gProfiler found this process and decided to skip", instead of "maybe gProfiler missed it..."). Explicitness is good.

Motivation and Context

Make it easier to understand when & why gProfiler decides to skip Java profiling.

How Has This Been Tested?

• Profiling a process with AP loaded (from a different path) - results in java;[Profiling skipped: async-profiler is already loaded].
• Profiling a process with unsupported JVM version / type - results in java;[Profiling skipped: profiling this JVM is not supported].
• Profiling a process after safemode has disabled profiling completely - results in the profiling skipped stack, with the safemode reason in it. For example: java;[Profiling skipped: disabled due to hserr]

Automatic tests for all the above ^^

[DanielShaulov]

Minor comments, looks good.
I think you are also missing a test for bad/incompatible java version, but I understand if it is too hard to do and not worth it

[Jongy]

Minor comments, looks good.
I think you are also missing a test for bad/incompatible java version, but I understand if it is too hard to do and not worth it

We have test_java_safemode_version_check and test_java_safemode_build_number_check, but no test for unsupported JVM type because it's indeed hard to implement.