Align default gson dependency version in generated provider SDKs with core SDK

[eon-pulumi-agent]

What

Bumps the hardcoded default com.google.code.gson:gson dependency version that the Java code generator injects into generated provider SDKs (build.gradle) from 2.8.9 to 2.10.1, and bumps the core SDK's own pin in sdk/java/pulumi/build.gradle from 2.10 to 2.10.1 so the two now match exactly.

Why (relates to #812)

#812 reports a Maven program hanging depending on whether a provider (e.g. azure-native) or com.pulumi:pulumi is listed first in pom.xml. The root cause identified in that thread was that generated provider SDKs pulled in different transitive versions of guava/gson than the core Pulumi Java SDK, and since these end up at the same depth in the dependency graph, Maven's dependency mediation breaks the tie using declaration order, so the resolved version (and thus runtime behavior) depended on pom.xml ordering.

The guava half of that problem was fixed shortly after the issue was filed (generated provider SDKs no longer declare a default guava dependency at all, so there's no more guava/grpc-netty classpath conflict — I verified this is no longer order-dependent with the current published com.pulumi:azure-native and com.pulumi:pulumi artifacts).

However, gson was never brought back in sync: pkg/codegen/java/package_info.go still defaulted generated provider SDKs to gson:2.8.9, while the core SDK's build.gradle has since moved to gson:2.10. I reproduced this with the real, currently-published Maven Central artifacts — the resolved gson version differed (2.8.9 vs 2.10) purely based on which dependency was listed first in a test pom.xml.

gson:2.10 isn't representable through the semver.Version type used here (Gson dropped the patch component for that release), so this change moves both pins to gson:2.10.1, a real, three-component, semver-parseable Gson release, so they line up exactly.

Testing

• cd sdk/java && gradle build — core SDK unit tests pass with the new gson pin.
• cd pkg/codegen/java && go test ./... (i.e. make codegen_tests) — full suite passes, including real gradle build/gradle test compiles of ~80 generated SDK fixtures against the new default.
• PULUMI_ACCEPT=true regenerated the 35 golden build.gradle fixtures affected; each diff is exactly the one-line version bump.
• golangci-lint run — clean.
• Re-ran the Maven dependency-tree repro from the issue against the (locally rebuilt) SDK + a mini test provider with both dependency orderings to confirm gson now resolves identically either way.

Note on the original "hang"

The exact hang described in #812 was almost certainly caused by the guava mismatch, which is already fixed on main. This PR closes out the remaining, more minor gson skew so generated provider SDKs stay fully consistent with the core SDK going forward, and adds a comment to WithDefaultDependencies explaining why these versions must be kept in sync, referencing this issue.

---

Created with Eon