Support for Nested Property Access in Fn::GetAtt for Registry Resources Complex Return Types

### Name of the resource

Other

### Resource name

All CFN resource returning complex types with GetAtt

### Description

I have noticed that Registry resources now return complex types (Lists of Maps, JSON Objects) from `Fn::GetAtt` attributes. Sometimes [even from `Ref`](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-lakeformation-principalpermissions.html).

The problem is that CloudFormation lacks intrinsic functions to access nested properties within these complex types, which makes many of these attributes effectively unusable for template orchestration. You can’t reasonably output just a single nested field from a stack, you can’t export it, and you usually can’t pass it to other resources in a useful way (say, `AWS::SSM::Parameter`), not even via `Fn::ToJsonString`.

I realize there may be cases where some resource type accepts that complex attribute as a parameter, but in that case it’s not clear why the full structure is even exposed via `GetAtt` to the user, instead of just passing a reference to the resource and letting the provider handle it internally.

As a user this is confusing (certainly to me) and not a great experience.

Here are a couple of examples of problematic resources (just because I stumbled on them, I’m sure there are others):

- [`AWS::ECS::ExpressGatewayService`](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-ecs-expressgatewayservice-expressgatewayserviceconfiguration.html) returns `ActiveConfigurations` as a **List of Maps**. I cannot extract any of the properties from those entries inside the template.

- [`AWS::LakeFormation::PrincipalPermissions`](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-lakeformation-principalpermissions.html) returns `PrincipalIdentifier` as a JSON Object and `ResourceIdentifier` as another JSON Object, and `Ref` on this resource returns both, concatenated with a `|` (pipe) symbol.

One way to improve the situation would be to add support for accessing nested properties within complex `GetAtt` / `Ref` return types. Some ideas off the top of my head:

- Deep-path `GetAtt` syntax (similar to `AWS::CloudFormation::Stack` Outputs), e.g.:

```yaml
!GetAtt Resource.Attribute[0].Key
```

- New intrinsic functions like `Fn::GetJsonProperty` or `Fn::GetMapValue`.

- A query-language-style intrinsic (JMESPath / JSONPath / jq), e.g. `Fn::Jq`.

There are probably better ideas. Some of them were already explored in #68 and I would recommend revisiting that issue, as there are solid suggestions there ([for example this comment](https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/68#issuecomment-517518292)).

Current workarounds I can think of:

1. `AWS::CloudFormation::Macro` with a custom Lambda that parses and rewrites things (feels heavy-handed).
2. Custom Resources that call the service APIs and re-expose flattened attributes (also heavy-handed).
3. Use Terraform.
3. Abandon any hope. Hopefully not.

And CDK doesn’t help here, because it still compiles down to CloudFormation templates with the same intrinsic limitations.

Maybe this is something that is already being worked on, but it would be very helpful to at least get some guidance and forward-looking direction for users / the community.

### Other Details

_No response_

Start by reviewing the proposed deep-path GetAtt, GetJsonProperty/GetMapValue, and query-language approaches, then read the related discussion in issue #68. Use the AWS::ECS::ExpressGatewayService and AWS::LakeFormation::PrincipalPermissions examples as entry points; done would require a decided scope and specified CloudFormation behavior, but no source files or tests are named.

Written by the indexing model from the issue text.