feat(trace): fall back to binary scope when project scope is unsupported

[dodoazzurro]

Why

When --scope=project is used against a binary that does not carry Go build info (e.g. built as command-line-arguments, a non-Go binary, or one without a .go_buildinfo section), xcover would hard-fail with:

failed to resolve functions: failed to detect Go module path (is this a Go binary?): binary was built as command-line-arguments

Project scoping is best-effort: if the binary does not support it, binary scope is the right fallback rather than an outright failure.

What

Introduces a typed sentinel ErrProjectScopeUnsupported that GoProjectResolver returns whenever build info is missing or unusable. defaultResolver wraps the project resolver with withProjectFallback, which catches that sentinel, logs a warning, and delegates to SymbolTableResolver.

Any other error from the primary resolver is still propagated as-is, so genuine failures (e.g. empty symbol table) are not swallowed.

How

• ErrProjectScopeUnsupported sentinel in tracee_errors.go - inspectable via errors.Is
• withProjectFallback(primary, fallback, logger) - a pure resolver wrapper, easy to test in isolation and composable if other scope types need the same pattern later
• defaultResolver in tracee.go builds the fallback chain only for ScopeProject; explicit custom resolvers passed via WithResolver are unaffected
• Unit tests for all three paths: primary success, fallback on unsupported, propagation of unrelated errors