Unified persistent resource API

## Background and Motivation

We've supported running container resources with different lifetimes (persistent vs. session) for a while now and have had a `WithLifetime(ContainerLifetime)` API that took one of two enum values (`ContainerLifetime.Persistent`, `ContainerLifetime.Session`). However, we're adding several new persistent resources features in #17112 that strain that specific API to the point where we should consider some changes.

In particular, we're adding persistent executables (meaning ContainerLifetime isn't suitable for all resource types) and we're adding more advanced lifetimes (such as tying a resource's lifetime to a parent process like an IDE) which require additional arguments beyond just the lifetime type.

Beyond just new features, we also need to consider the impact of our API choices on polyglot app hosts.

## Proposed API

Instead of an Enum based API, we could introduce multiple lifetime specific APIs:

`WithSessionLifetime()`

`WithPersistentLifetime()`

`WithParentProcessLifetime(parentProcessReferenece)`

`WithLifetimeOf(resource)`

The advantage being that we can consistently represent lifetime for both containers and executables, there's no conflict with the existing container WithLifetime API, and it's easy to represent the API for both .NET and polyglot AppHosts.

## Usage Examples

## Alternative Designs

An alternative design would be to introduce a new `Lifetime` enum and use `WithLifetime(Lifetime)` for session and persistent lifetime resources, plus new dedicated APIs for `WithParentProcessLifetime` (and optionally `WithLifetimeOf`, as it's merely a helper to replace a common pattern we had in several resources). The plus is that the standard API stays consistent with our old design, but it means we have two separate invocation modes, one that's enum based, and one that takes a specific argument.

## Risks

The main risk would be confusion/discoverability issues.