Support start delay in continue-as-new options

Is your feature request related to a problem? Please describe.
The same as https://github.com/temporalio/temporal/issues/12162: "The use case here is to prevent from having to put a long timer (months) at the top of a workflow and force maintaining history compatibility for as long as that workflow lives."

Workflows that implement some type of loop-with-sleep pattern could benefit from this feature. Currently they would need to be long lived workflows (with the accompanying history compatibility constraints), but adding a start delay to continue-as-new options would allow them to be represented as a series of short-lived workflows.

More generally, any workflow that needs to perform work after sleeping could potentially be rewritten in a "recursive" way using this feature. They would then benefit from being a short-lived workflow and e.g. could better take advantage of worker versioning.

Describe the solution you'd like
Support start delay in continue-as-new options.

Describe alternatives you've considered
The alternatives today are:

• Sleep within the workflow, but this requires you to maintain history compatibility for the duration of the sleep
• Start a new workflow within an activity, but that loses the parent-child relationship and history.

Additional context
https://restate.dev/blog/code-that-sleeps-for-a-month/#control-loops describes a similar approach for a different durable execution tool.

Start by locating the service's continue-as-new options and workflow lifecycle entry points; the issue names no files or tests. Done means supporting a start delay for continue-as-new while preserving the parent-child relationship and history benefits described for loop-with-sleep workflows.