Resources with multiple args

I hit the following problem whilst trying to migrate the rust extensions from the community toolkit into the aspire repo.

`WithArgs()` makes an assumption that resources have exactly one set of args.
While this seems reasonable at first, this does sometimes break down, as a number of tools allow you to pass args to the tool itself and then args to something the tool invokes (often using a `--` to separate tool args from app args).
e.g. `dotnet tool exec -- `

We have quite a few situations with this behavior, with each taking slightly different solutions:

- Containers have runtime arguments and app args (`.WithContainerRuntimeArgs()` and `.WithArgs()`)
- Dotnet Tools have arguments passed to `dotnet tool exec`, and then arguments passed to the application (separated by a `--` argument). (The tool arguments are internal and work by ensuring it registers the first `.WithArgs()` annotation to get the tool argument in before any arguments.)
- Go has `WithArgs()` and `WithAppArgs()` to control arguments to the launcher.
- Projects have arguments passed to the app itself, and other arguments passed to `dotnet` (although again, most of these are handled internally by Aspire and are not exposed to users).

There are some similar cases like `npm install` and `pip install` where there are two separate sets of args, but they are also two separate processes. They are slightly differen scenarios, but mentioning them for completion.

## How to handle resources with multiple sets of args

We're pretty much stuck with `.WithArgs()` due to `IResourceWithArgs`.
And we'll need two separate methods for two separate args (Potentially more if cases came up with more than 2 sets of args).
Which in my mind leaves the following options:

1. Do nothing - it's up to consumers to know `--` is the magic separator and use that to manipulate app vs tool args.
2. `WithArgs()` for app args, and `WithXYZArgs()` for tools (e.g. `ContainerResource`).
3. `WithArgs()` handles tool args, whilst `WithAppArgs()` handles app args (e.g. `GoAppResource`).
4. Don't standardise and let some apps let `WithArgs()` target app args, whilst others target tool args.

1 feels like a bad option, and isn't even an option in some cases. So it feels like the choice is really between 2 and 3.

My personal preference would be option 2 - let `WithArgs()` apply to app args, and then use `WithTOOLArgs()`.

There is an argument to make that the method naming / resource type could impact which portion the general `WithArgs()` method affects, but this also feels like it could get very inconsistent and confusing.

- `.WithRustApp()` you might assume `.WithArgs()` applies to your app args (based on `RustApp`), and need `.WithCargoArgs()` to manage cargo args.
- `.WithCargoApp()` you might assume `.WithArgs()` applies to Cargo (based on `CargoApp`), needing `.WithAppArgs()` to add args to your app.

Start by tracing IResourceWithArgs and WithArgs(), then compare the existing WithContainerRuntimeArgs(), WithAppArgs(), and resource-specific argument handling described for containers, dotnet tools, Go, and projects. Done means the project has agreed on a consistent API convention for multiple argument sets and documented which method targets each set.

Written by the indexing model from the issue text.