Support SELECT/INSERT/UPDATE/DELETE db operation + span names

[damemi]

Ref #743

From the semconv for db spans:

Database spans MUST follow the overall [guidelines for span names](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.37.0/specification/trace/api.md#span).

The span name SHOULD be {db.query.summary} if a summary is available.

If no summary is available, the span name SHOULD be {db.operation.name} {target} provided that a (low-cardinality) db.operation.name is available (see below for the exact definition of the [{target}](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/database-spans.md#target-placeholder) placeholder).

If a (low-cardinality) db.operation.name is not available, database span names SHOULD default to the [{target}](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/database-spans.md#target-placeholder).

If neither {db.operation.name} nor {target} are available, span name SHOULD be {db.system}.

Semantic conventions for individual database systems MAY specify different span name format.

The {target} SHOULD describe the entity that the operation is performed against and SHOULD adhere to one of the following values, provided they are accessible:

db.collection.name SHOULD be used for data manipulation operations or operations on a database collection.
db.namespace SHOULD be used for operations on a specific database namespace.
server.address:server.port SHOULD be used for other operations not targeting any specific database(s) or collection(s)
If a corresponding {target} value is not available for a specific operation, the instrumentation SHOULD omit the {target}. For example, for an operation describing SQL query on an anonymous table like SELECT * FROM (SELECT * FROM table) t, span name should be SELECT.

We don't have collection (table), namespace, or server.address readily available (right now), but we can at least parse certain operations. We can also support more over time. So this gets us at least a couple useful span names besides DB (fallback for unsupported operations)

This means we can also set db.operation.name with that same value when it is available.

[MrAlias]

This looks like an exciting change. Mainly small comments outside of the compatibility policy issue.

Do we need to support older versions of Go? Would that break any downstream users of go.opentelemetry.io/auto?

[damemi]

Update from the SIG call feedback this week, I pinned Vitess to v0.20.2 which is on Go 1.22.7 (our version) and this is the error: https://github.com/open-telemetry/opentelemetry-go-instrumentation/actions/runs/12181495669/job/33978276098?pr=1253#step:6:434

link: vitess.io/vitess/go/hack: invalid reference to runtime.roundupsize

This is probably because we build our image on go 1.23 (which makes sense, we ship an artifact based on that so it should use the latest runtime).

Based on that, I think the only option is to undo the vitess work and revert this to just the basic command parsing I originally had. Which is a bummer, because vitess is a lot richer :\ @MrAlias does that sound good to you?

[MrAlias]

I agree with the revert to the other sql parsing package. I think we should still be able to support table parsing though based on #1253 (comment)

[damemi]

@MrAlias @RonFed this is ready for another round of review, I reverted back to the other library and we'll just support basic statements + collection when available

[RonFed]

left 2 non-blocking comments

[MrAlias]

🏅