Minimalist `dapr init`, ideally as the default

## Improvement

When `dapr init` is called, by default it creates Redis and Zipkin containers.

In theory this _could_ be helpful, though I think it ends up being misleading to newcomers and mildly fault prone:

- If someone is already working with a local development setup that uses Redis, port `6379` is almost guaranteed to already be in use
- Zipkin prescribes a specific telemetry solution, I'd also argue most users never end up working with this container
- It sets a confusing precedent as part of a "minimalist Dapr experience". None of the Dapr components (scheduler, placement) require these containers. (😅 I actually snagged on this when I was first learning Dapr!)

You can see an example of the impact of this default in [some documentation I'm working on](https://github.com/diagrid-labs/catalyst-order-workflow-dotnet/blob/18d8014535078602677b9f0b6cfc69a279554fd8/running.md?plain=1#L25):

```
3. Run `docker rm dapr_redis dapr_zipkin --force` -- this cleans up some default containers we'll be replacing
```

## Fix

I think it's harmless to remove starting these two containers as part of the default `init` flow. If it's something we really want to offer, then make it opt-in.

### See also

- https://github.com/dapr/cli/issues/175
- https://github.com/dapr/cli/pull/1523

## Release Note

RELEASE NOTE: **FIX** Make supporting containers optional during `init`.