ci: introduce continuous smoke testing

[Julio-Guerra]

What does this PR do?

Introduce a github workflow to run "smoke tests" whose goal is to very simply check that dd-trace-go works (eg. compiling only) under some given conditions/environments.

I bootstrapped it with a smoke test of dd-trace-go after the go.mod file got updated with go get -u where we basically expect our core packages (tracer, profiler and appsec) to still compile and work after a new minor release of our dependencies.

Motivation

1. Uncover go get -u issues on new go.mod deps before releasing.
   Related to [BUG] v1.44.0 seems to pull in a broken pkg #1607
2. Uncover go get -u issues on existing go.mod deps when a new breaking change has been introduced in one of our unstable (v0) dependencies

Describe how to test/QA your changes

Reviewer's Checklist

• If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
• Changed code has unit tests for its functionality.
• If this interacts with the agent in a new way, a system test has been added.

[pr-commenter]

Benchmarks

Comparing candidate commit ab1dca8 in PR branch julio.guerra/smoke-tests with baseline commit 0ab9332 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 6 cases.

[Julio-Guerra]

I temporarily enabled the workflow on pull requests to see it working at https://github.com/DataDog/dd-trace-go/actions/runs/3643501586/jobs/6151789596 and it properly detects the go get -u issue we currently have

[felixge]

LGTM, but would prefer a better name.

[felixge]

Why isn't this called "go get -u test" or something similar?

[Julio-Guerra]

I'm expecting to put more smoke tests cases as jobs of this workflow.
The next one I have in mind is go mod vendor where we used to have many issues in the past (mostly before go modules existed ^^') where some files were not vendored and it was leading to compilation issues too.