Native profile symbolization in the backend when using OTel ebpf-profiler

#### Is your feature request related to a problem? Please describe.

Experimental support for receiving profiles from OpenTelemetry sources has landed (documented in #3713). This enables using Pyroscope with the [OTel ebpf-profiler](https://github.com/open-telemetry/opentelemetry-ebpf-profiler) as shown in [this example](https://github.com/grafana/pyroscope/tree/main/examples/grafana-agent-auto-instrumentation/ebpf-otel).

The [ebpf-profiler README](https://github.com/open-telemetry/opentelemetry-ebpf-profiler#symbolization) specifies that symbolization of stack traces should be done in the backend and that there should be a way to upload private executables to the backend:

> For native code the symbolization occurs in the backend. Stack frames are sent as file IDs and the offset within the file and the symbolization service is then responsible for assigning the correct function name, source file and lines in the background. Symbols for open-source software installed from OS package repos are pulled in from our global symbolization infrastructure and symbols for private executables can be manually uploaded by the customer.

#### Describe the solution you'd like

Ideally, the profiler itself would discover the backend and upload executables for which no public debuginfo is found. This is the approach taken by [parca-agent](https://github.com/parca-dev/parca-agent).

At least there should be a way to manually upload executables to Pyroscope for symbolization.

#### Describe alternatives you've considered

As far as I can tell there is no infrastructure in Pyroscope for symbolization of native stack traces right now.

#### Additional context

Any implementation of symbolization should IMHO offer the possibility of using the system's `addr2line` utility, as custom implementations can be error-prone (see https://github.com/parca-dev/parca/issues/5291).