…trap shadow jar

The problem was that `./gradlew shadowJar --rerun-tasks` execution was
non-deterministic depending on the state of the build. This resulted in
`otel-bootstrap` jar sometimes embedded the full set of OTel semconv
classes (~189), and sometimes only the Java-compiled ones (~4).

### Root cause

`unpackJars` and `compileJava` shared the same output directory
(`compileJava.destinationDirectory` = `build/classes/java/main/`).

After a first successful build, `main/` contained **instrumented** OTel
classes (modified in-place by the ByteBuddy `doLast` action).
But on the next execution **with** `--rerun-tasks`:

1. `unpackJars` re-ran and wrote **original** (un-instrumented) OTel
   classes to `main/`, replacing the previously-instrumented versions.
2. The Java compiler detected that files in its output directory had
   changed (instrumented → original) and switched to
   **non-incremental mode**, in the info log:

   Not incremental: removing prior outputs"

   thus deleting **all** prior outputs from `main/` — including the
   OTel classes just placed by `unpackJars`.
3. In the end only the project's compiled and processed classes files
   remained.

The bug was not manifested on a clean state because `main/` had no prior
files for the Java compiler to compare against.

---

This commit fixes the situation by filling a gap in the build time
instrumentation plugin:

- `unpackJars`'s output is now a dedicated `build/otel-unpacked/`
  directory to avoid overlap with `compileJava.destinationDirectory`.
- Build time instrumentation plugin allow to declare a
  `includeClassDirectories` used as task input, its classes will be
  included for post processing.

Because `build/otel-unpacked/` is now only written to by `unpackJars`,
Gradle's stale-output cleanup for `compileJava` never touches it.

(cherry picked from commit 127989e)

(cherry picked from commit dcd1f67)

The `unpackJars` task dependency do not have to be declared as a
dependency of the compile task, however it should be declared as
an included input of the build time instrumentation.

Also, the `unpackJars` is now a `Sync` task to deletes files that
are no longer in the source JARs.

(cherry picked from commit 3cc39c8)

(cherry picked from commit 2dc754d)