feat: Change to managed IAM policy for ecs tasks with path attrribute support over inline role policy

[partlythomas]

Description

Note: New PR to base off from wip/v6 branch instead.

The following changes are proposed:

• Change the ECS tasks role policy to be managed as a separate aws_iam_policy resource rather than the inline type aws_iam_role_policy
• Add explicit role policy attachment to attach the managed ECS tasks policy to the role.
• Add support for specifying path of the ECS tasks policy.

Motivation and Context

The change opens for more flexibility in the ECS tasks role for specifying the path of the policy.
This also aligns the ECS tasks role and policy with the same pattern that the existing role and policy for the ECS task execution role in the module.

Breaking Changes

• If ECS task role is not used (i.e. conditions for creating task role is not met), no changes will be picked up by Terraform.
• If ECS task role is used (i.e. conditions for creating task role is not met), the inline iam role policy will be replaced by the iam policy and role policy attachment.

Both cases applies both with or without the path configuration of the policy being set with the new variable tasks_iam_policy_path.

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using the examples/complete project deployed cleanly first, with later addition of ecs service variable input of tasks_iam_policy_path prompting to take the changes into effect. The changes was deployed sucessfully.

• I have executed pre-commit run -a on my pull request

[partlythomas]

This is changed from how the logic was used in the master branch. The > 0 logic only creates the policy if there are statements defined. The change of '!= null' (which is not found in master branch) can attempt to create the policy if just an empty list is passed.

I followed the logic from the master branch, but have no preference if the != null logic is to be used instead.

[bryantbiggs]

we should not change the logic, it should be checking != null

[partlythomas]

Corrected to != null now, as is case in the wip/v6 branch currently.