[Feature]: Load plugins dynamically from Lambda layers

[zhongkechen]

What would you like?

I would like the SDK to support opt-in discovery and registration of
DurableExecutionPlugin implementations from runtime dependencies during cold
start.

The target Lambda workflow is:

1. Publish a plugin JAR in a Lambda layer under java/lib.
2. Attach the layer to an existing function.
3. Set configuration such as
   DURABLE_EXECUTION_PLUGINS=otel,com.example.audit.
4. Have the SDK load and register those plugins without rebuilding or
   repackaging the function's application artifact.

Today plugins must be instantiated in application code and passed to
DurableConfig.builder().withPlugins(...). Making a JAR available on the
Lambda class path is not sufficient, and Java-agent extension discovery is
separate from Durable Execution plugin registration.

The dynamic path should:

• Be explicitly enabled; an unset configuration must preserve current behavior.
• Load plugins once during cold-start configuration.
• Preserve configured ordering and support multiple plugins.
• Resolve providers from the normal application and Lambda-layer class path.
• Validate provider type and SDK/API compatibility with actionable failures.
• Define duplicate handling when a plugin is both explicitly and dynamically
  registered.
• Preserve withPlugins(...) for applications that prefer code-based
  registration.

Possible Implementation

Add a provider/factory SPI, for example DurableExecutionPluginProvider, and
discover implementations with ServiceLoader. Providers could expose a stable
name and create a DurableExecutionPlugin, while the environment variable acts
as an explicit allow-list rather than automatically executing every provider
found on the class path.

An alternative is supporting fully qualified class names with reflection, but a
provider interface would avoid requiring every plugin to have a public no-arg
constructor and would give the SDK a place to perform compatibility validation.

Provider-specific settings could remain in namespaced environment variables.

Is this a breaking change?

No

Does this require an RFC?

Yes

Additional Context

The immediate use case is distributing observability integrations, including
OpenTelemetry, independently from the function artifact. The same capability is
useful for logging, metrics, auditing, and other instrumentation plugins.

Attaching a layer and updating environment variables is still a Lambda
configuration deployment, but it avoids rebuilding and republishing application
code solely to add or update instrumentation.