[julia] Emit Project.toml, track OpenAPI.jl release-0.2, fix exportOperations

[tanmaykm]

Housekeeping for the julia-client / julia-server generators, following the OpenAPI.jl 0.2.x / 1.x split (JuliaComputing/OpenAPI.jl#104).

OpenAPI.jl main now hosts a 1.x pure-Julia generator with a different runtime API; the 0.2.x series that these generators target is maintained on the release-0.2 branch. This PR keeps generated code working through that transition and fixes two standing issues:

1. Emit a Project.toml with the generated code (both generators). Generated modules previously declared no dependencies, so a fresh environment doing Pkg.add("OpenAPI") would resolve to OpenAPI.jl 1.x and fail on the missing 0.2.x API (OpenAPI.Clients / OpenAPI.Servers). The emitted Project.toml names the package (with a deterministic UUID derived from the package name, so regeneration is reproducible), declares the dependencies the generated code uses (OpenAPI, Dates, TimeZones, plus HTTP/URIs for the server), and pins OpenAPI = "0.2".
2. Test samples against the maintained 0.2.x branch. samples-julia.yaml pinned the OpenAPI.jl checkout to the v0.2.0 tag (2023), so recent 0.2.x fixes were never exercised against freshly generated samples. It now checks out release-0.2.
3. Fix the exportOperations option in JuliaClientCodegen: it called setExportModels and wrote the exportModels value through to the exportOperations template property, so the two options were not separable.
4. Document the runtime compatibility boundary in the generated READMEs: these generators target OpenAPI.jl 0.2.x, and their output does not run on OpenAPI.jl 1.x (which has its own native generator, OpenAPI.client / OpenAPI.server).
5. Delete the stale docs/generators/julia.md, which documented a julia generator that is not registered (the registered generators are julia-client and julia-server, which have their own docs).

PR checklist

• Read the contribution guidelines.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. (cc: @wing328 could you please take a look)

---

Summary by cubic

Keeps julia-client and julia-server generated code working after OpenAPI.jl split into a 1.x pure-Julia generator and a 0.2.x maintenance series that these generators target. Generated modules previously declared no dependencies, so a fresh environment could resolve to the incompatible OpenAPI 1.x; the generators now emit a Project.toml that pins OpenAPI = "0.2" and declares Dates, TimeZones, and (for servers) HTTP/URIs. The package UUID is derived deterministically from the package name so regeneration is reproducible.

Bug Fixes

• Fixed exportOperations in JuliaClientCodegen writing through the exportModels setter and value.
• Samples now test against the maintained release-0.2 branch of OpenAPI.jl instead of the stale v0.2.0 tag.
• Removed docs/generators/julia.md, which documented an unregistered julia generator that duplicates julia-client/julia-server docs.

^{Written for commit 68cef24. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 14 files

_{Re-trigger cubic}