[Profiling] Don't group by address if executable is known but function is unknown

[rockdaboot]

This PR ignores the address or line number when grouping frames with unknown function name but known executable name.

Fully symbolized frames are not affected at all.
This change only affects how unsymbolized frames are grouped / aggregated.

For example, an unsymbolized lib.so.6 sill appear as a single entry in the TopN functions view, and no longer as hundreds of different entries.

In the flamegraph, this changed aggregation of frames leads to less complexity.
Here are screenshots that show the change as it is otherwise hard to phrase and understand.

Before

After

[elasticsearchmachine]

Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services)

[christos68k]

For an expert, this can also be seen as misleading as it hides the separation of different callers (even if the caller information is unknown, the fact that separate callers are shown can be useful in itself). But given our target audience and that it doesn't affect the relative order of CPU usage across executables and thread names, I think it's OK to introduce a simplification such as this and iterate.

[rockdaboot]

For an expert, this can also be seen as misleading as it hides the separation of different callers

As you say, our target audience isn't the expert who takes the addresses and puts them in Ghidra or IDA to make use of it. But also, if enough customers ask for more details, we can add a setting to turn the details on again.