E2e workspace

Picks up the check regrouping (checks are now reported as `<group>:<check>`,
e.g. install:registers-sdk) and a new `chain` group covering modules that
depend on each other by local path.

The new chain checks fail here: after `dagger generate`, a chained module
still lacks src/generated/java/io/dagger/gen/entrypoint/Entrypoint.java, so it
cannot load. All 20 pre-existing checks pass, so this is a gap the new checks
surface rather than a regression from the bump.

Signed-off-by: Tom Chauveau <tom@dagger.io>

A module that depends on another by local path cannot resolve its own schema
until that dependency has been generated, so overlay the generated closure
onto the workspace before generating the module itself.

Reach for it only when there is a local dependency to stage.
generateLocalDependencies restores the workspace's owning client context
before it checks whether there is anything to stage, so it fails outright on
a synthetic workspace — the form Directory.asWorkspace produces, and what the
e2e checks build — even for a module with no dependencies at all. The engine
skips git dependencies and returns an empty changeset once none are left, so
the check only short-circuits work that would have been a no-op.

Signed-off-by: Yves Brissaud <yves@dagger.io>

The engine applies a generator's changeset relative to the client's cwd, but
generateModule staged and diffed everything workspace-rooted. Generating from
inside a module therefore nested every path under the cwd a second time and
left the module itself ungenerated, which is what the sdk-sdk chain checks
caught.

Re-root the changeset at the cwd, and raise for a module discovered above it
by find-up rather than silently dropping changes a cwd-relative changeset
cannot express.

Signed-off-by: Yves Brissaud <yves@dagger.io>

target/ is build output, but three paths treated it as source, and a stale
class file there beats the source it was compiled from: it is newer, so
maven-compiler-plugin skips recompiling and the stale class is packaged.

  - the runtime copied the whole module context into the build container, so
    an IDE-built class came along. Eclipse JDT writes a stub that throws
    "Unresolved compilation problems" at runtime, which is what a user hit
    after opening a module in an editor before loading it.
  - generateModule mounted the same output when compiling the entrypoint.
  - initModule fed templates/<name>/ to the renderer, which substitutes the
    module name into every file it walks — including .class bytes, whose
    constant pool it corrupts. target/ is gitignored, so this only bites on a
    developer's checkout, where it broke module scaffolding outright.

Exclude **/target/** at all three, matching the discovery pass, which already
skips it.

Signed-off-by: Yves Brissaud <yves@dagger.io>

A scaffolded Java module carried no git metadata, so a user who ran maven or
opened the module in an IDE committed target/ along with their sources. The
template's own pom.xml already pointed at both files — "the whole sdk/
directory is generated (see .gitattributes / .gitignore)" — but nothing
created them.

sdk/ and src/generated/ are generated yet committed on purpose: the runtime
builds from committed sources. So they are marked linguist-generated rather
than ignored, collapsing them in diffs and keeping them out of language
stats, the same treatment go-sdk gives dagger.gen.go.

This is hygiene, not a safeguard: withDirectory takes gitignore: false by
default, so these rules do not affect what generation and the runtime read.
Excluding build output from a build is what does that.

Signed-off-by: Yves Brissaud <yves@dagger.io>

- update sdk-sdk
- ignore target directories on build
- add .gitignore and .gitattributes