Fix data race in MaybeNotifyAPMAgent

[athre0z]

MaybeNotifyAPMAgent could previously access the interpreter map while it was being updated in another goroutine during PID event processing. This commit correctly takes the lock to prevent this in the future.

This doesn't happen much during normal operation, but becomes increasingly likely with higher sampling rates.

Example crash

fatal error: concurrent map read and map write

goroutine 201 [running]:
go.opentelemetry.io/ebpf-profiler/processmanager.(*ProcessManager).MaybeNotifyAPMAgent(0xc006792000?, 0xc006180820, {{0xcf22de1f18bae9f9?, 0x0?}}, 0x1)
        /root/zymtrace/services/profiler/ebpf-profiler/processmanager/manager.go:323 +0x51
go.opentelemetry.io/ebpf-profiler/tracehandler.(*traceHandler).HandleTrace(0xc006780120, 0xc006180820)
        /root/zymtrace/services/profiler/ebpf-profiler/tracehandler/tracehandler.go:150 +0x2a2
go.opentelemetry.io/ebpf-profiler/tracehandler.Start.func1()
        /root/zymtrace/services/profiler/ebpf-profiler/tracehandler/tracehandler.go:196 +0x173
created by go.opentelemetry.io/ebpf-profiler/tracehandler.Start in goroutine 1
        /root/zymtrace/services/profiler/ebpf-profiler/tracehandler/tracehandler.go:185 +0x174

[athre0z]

@fabled can you please merge? It seems that approvers no longer have permissions to do so themselves.