Use Workspace.withDirectory for init once beta.11 is out

[TomChv]

Blocked on the v1.0.0-beta.11 release.

dagger/dagger#13956 (fixes dagger/dagger#13955) splits Workspace.withNewDirectory in two:

• withNewDirectory now replaces whatever the path held, on every workspace kind — host-backed, value and git alike. Before, it only replaced on a host-backed checkout and merged on the other two.
• The new Workspace.withDirectory merges the source onto what the path already holds, the same contract Directory.withDirectory has.

The read-back-and-layer we wrote by hand in #14 is exactly that second field, so it can go away.

What to change

Once dagger.json moves to engineVersion: v1.0.0-beta.11:

initModule (python-sdk.dang:147) layers the template onto the destination itself, so init never removes a user's files nor the module config the engine wrote at modPath moments earlier:

# withNewDirectory replaces the directory it writes, so layer the
# template onto what is already there: init must never remove a user's
# files.
ws
  .withNewDirectory("/" + modPath, existingDir(ws, modPath).withDirectory(".", templateSource))
  .changes(ws)

becomes:

ws.withDirectory("/" + modPath, templateSource).changes(ws)

and the comment goes with it — the field name carries it now.

That was existingDir's only caller, so the helper (python-sdk.dang:159) becomes dead and should go too. Unlike go-sdk, this SDK does not feed the destination back into codegen, so nothing else needs it.

Guards

dagger check 'e-2-e:*', in particular e-2-e:init-over-existing-check — the regression check added in #14 for exactly this.