Replace probe.Event with ptrace.ScopeSpans

[MrAlias]

Resolve #1125

This implements part of #1177. It removes the probe.Event type and replaces its use with ptrace.ScopeSpans. It does not replace the Controller with a collector receiver and new Handler type (like #1177). The goal here is to lay the foundation from which we can build out the collector receiver and generalize the probe handler.

PR Size considerations

This PR is large. I have done my best to structure commits so they can be reviewed as independent additions. The commits are not self contained (most will not compile/test successfully). Because of this I know of no better way to split this PR into something smaller. Suggestions are welcome if reviews think it is needed and have them.

Important to note

For the most part, this PR is a direct translation from our Event type to ptrace. There are a few notable changes that have also been made.

Probe creations functions now accept a version

The probe processing logic now produces a scope defining a tracer. This means a version of the "SDK" is needed for that scope.

Probes that do not receive a tracer scope from their events will now be passed the auto version to add to their scope.

This restructure is something that will eventually be needed for #1105.

ptrace.ScopeSpans is used instead of ptrace.Traces

The ptrace.Traces data-type is not used as probes should not be defining resource level attributes. That is left to the Manager/Controller.

For things like the auto/sdk probe, it may be necessary to pass along the version of the sdk package used in the future. When needed, it can be added as a scope attribute (once scope attributes are supported in the Controller or its replacement).

Use net.SplitHostPort in grpc client probe

Instead of parsing the address with the strings package, use the dedicated net.SplitHostPort function to parse the remote address.

Check SpanKindServer in auto/sdk probe e2e test

The collector will default to SpanKindInternal when the span kind is not set. We were explicitly setting the main span to this kind before. Instead set it to another kind to validate functionality.

Fix expected flags in e2e tests

Many e2e tests had 768 (0b11000000) as their span flags. I'm not entirely sure why they were expecting this, nor how it was getting set. But, ultimately, the second least-significant digit is not an OTel recognized flag (yet). Therefore, it should not be set.

This data-model switch seems to have fixed this. The tests have been updated appropriately.

[grcevski]

LGTM! This looks good to me, it took a bit of time to review, I like the code design changes. I wasn't able to check every detail, but the tests pass and there are new unit tests for the new code.

[RonFed]

Added a few non-blocking comments. This looks awesome.