[Fargate] [Task Resources]: Loosen CPU/memory coupling

**Tell us about your request**
I'd like to see the coupling between CPU and memory in Fargate task resource allocations loosened or removed. In case there's any doubt, I mean the minimum number of vCPUs allocated for a given memory allocation, or the minimum memory allocated for a given number of vCPUs.

This is similar to #79 but more related to the balance between CPU and memory than the minimum values.

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

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
Currently if you have a task that requires 8 GB of memory but has low CPU requirements, the minimum CPU allocation is 1.0 vCPUs.; or you may have a task that warrants 4.0 vCPUs but needs only a small fraction of the 8 GB of memory that is the minimum you may allocate to such a task. In either case you must over-provision either CPU or memory resources to satisfy the resource constraints of the task.

In our specific case we are skewed heavily towards higher memory usage. If we host ECS on our own EC2 instances then by choosing R-series instance types we can gain a lot of efficiency. I'd like to see a similar degree of flexibility in Fargate task resource allocations as we have in EC2 instance types.

The recent price drops for Fargate tasks (which are very welcome!) have made this even more significant for memory-skewed tasks since even with the minimum CPU allocation, a Fargate task is now billed much higher for its CPU resources than its memory resources. The pricing examples on the [pricing page](https://aws.amazon.com/fargate/pricing/) appear to be out of date as I write this, incidentally.

**Are you currently working around this issue?**
We host ECS on our own EC2 instances, using R5 instance types.

The issue names no repository files, tests, or implementation entry points. Start by researching the documented Fargate CPU and memory allocation constraints and how ECS task definitions express them. Done would require an agreed set of supported combinations that avoids unnecessary CPU or memory over-provisioning.

Written by the indexing model from the issue text.