[ECS] [request]: Enable ECS Exec when using run-task on clusters with managed scaling and on tasks launched using ASG capacity providers

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
ECS Exec allows us to send commands to some ECS tasks remotely. The guide at https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html mentions several limitations of ECS Exec. I would like the following two limitations to be lifted:
1. ECS Exec is not currently supported for tasks launched using an Auto Scaling group capacity provider.
2. You cannot use ECS Exec when you use `run-task` to launch a task on a cluster that uses managed scaling with asynchronous placement (launch a task with no instance).

In my experience, the two points above aren't strictly accurate, The two listed behaviors are currently unreliable, but they don't seem completely unsupported or impossible in my testing. I hope to see these behaviors become reliable and supported.

**Which service(s) is this request for?**
ECS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
My team has an automated workflow that will call the AWS ECS SDK to `run-task` for a task that is backed by an Auto Scaling group capacity provider. Ideally, for frugality reasons, we would also like to allow `run-task` to launch a task with no existing instance yet in service. These are the two cases that are called out above as unsupported.

**Are you currently working around this issue?**
Yes. In my initial testing, our automated workflow was intermittently succeeding and failing. Eventually, I narrowed this down to a warm/cold instance issue. I believe that the two behaviors above are intermittently failing because the ECS agent container must be running on an ECS instance before it receives a task with the "enable execute command" flag. If the ECS agent is not running or present, the "enable execute command" flag is lost, but `run-task` will still successfully launch the task.

In my case, the automated workflow I'm using takes ~15 minutes before it runs this task. Since the task is backed by an ASG capacity provider, I set the minimum size for the ASG to 1 at the beginning of the workflow. This ensures (barring hardware availability issues) that the instance is warmed up and has ECS agent present before `run-task` tries to place my task with execute command enabled. This unblocks our use-case.

One more thought: Since `run-task` is able to wait for an instance to scale up before placing the task, the task must be stored in some queue (internal to ECS) in the meantime. Is it possible to store the requested "enable execute command" flag alongside the queued task, to ensure that `enableExecuteCommand` is set to `true` when the task is placed? I believe this may help resolve the two limitations I've called out here.

Start with the ECS Exec guide and the run-task flow described in the issue, focusing on enableExecuteCommand with ASG capacity providers and managed scaling with asynchronous placement. Done means these scenarios are reliably supported rather than intermittently losing the execute-command setting, with the documented limitations updated accordingly.

Written by the indexing model from the issue text.